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The present inventions provide an inte- 
grated, modular array of administrative and sup- 
port services for electronic commerce and elec- 
tronic rights and transaction management These 
administrative and support services supply a se- 
cure foundation for conducting financial man- 
agement, rights management, certificate author- 
ity, rules clearing, usage clearing, secure directory 
services, and other transaction related capabilities 
functioning over a vast electronic network such as 
the Internet and/or over organ i ration internal In- 
tranets. These administrative and support services 
can be adapted to the specific needs of electronic 
commerce value chains. Electronic commerce par- 
ticipants can use these administrative and support 
services to support their interests, and can shape 
and reuse these services in response to competitive 
business realities. A Distributed Commerce Util- 
ity having a secure, programmable, distributed ar- 
chitecture provides administrative and support ser- 
vices. The Distributed Commerce Utility makes 
optimally efficient use of commerce administration resources, and can scale in a practical fashion to accommodate the demands of elec- 
tronic commerce growth. The Distributed Co mmer c e Utility may comprise a number of Commerce Utility Systems. These Commerce 
Utility Systems provide a web of infrastructure support available to, and reusable by, the entire electronic community and/or many or all 
of its^xutzcipants. Different support functions can be collected together in hierarchical and/or in networked relationships to suit various 
businessvmodels and/or other objectives. Modular support functions can be combined in different arrays to form different Commerce Utility 
Systems for different design implementations and purposes, These Commerce Utility Systems can be distributed across a large number of 
electronic appliances with varying degrees of distribution. 
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TRUSTED INFRASTRUCTURE SUPPORT SYSTEMS, 

METHODS AND TECHNIQUES FOR 
SECURE ELECTRONIC COMMERCE, ELECTRONIC 
TRANSACTIONS, COMMERCE PROCESS CONTROL 
5 AND AUTOMATION, DISTRIBUTED COMPUTING, AND 

RIGHTS MANAGEMENT 

Field of the Inventions 

These inventions generally relate to optimally bringing the 
efficiencies of modern computing and networking to the 
1 0 administration and support of electronic interactions and 

consequences and further relate to a secure architecture enabling 
distributed, trusted administration for electronic commerce. 

These inventions relate, in more detail, to a "Distributed 
Commerce Utility" - a foundation for the administration and 
1 5 support of electronic commerce and other electronic interaction and 
relationship environments. 

In still more detail, these inventions generally relate to: 

• efficient administration and support of electronic 
commerce and communications; 

20 • methods and technologies for electronic rights 

administration and support services; 

• techniques and arrangements for distributing 
administration and support services such as secure 
electronic transaction management/administration, 

25 electronic process control and automation, and clearing 

functions across and/or within an electronic network 
and/or virtual distribution environment; and/or 

1 



WO 98/10381 PCT/US96/14262 

• clearing, control, automation, and other administrative, 
infrastructure and support capabilities that collectively 
enable and support the operation of an efficient, secure, 
peer-to-peer collection of commerce participants within 

5 the human digital community. 

Background 

Efficient, effective societies require capabilities enabling 
their inhabitants to control the nature and consequences of their 
participation in interactions. Every community needs certain basic 
10 services, facilities and installations: 

• the post office delivers our mail, 

• the schools teach our children, 

• the highway department keeps our roads passable and in 
good repair, 

15 •the fire department puts out fires, 

• the power company delivers electrical power to our 
homes, 

• the telephone company connects people and electronic 
devices near and far and provides directory services 

20 when you don't know the right number, 

• banks keep our money safe, 

• cable TV and radio stations deliver news and 
entertainment programming to our homes. 

• police keep order, 

25 • the sanitation department collects refuse, and 

• social services support societal policies for the needy. 
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These and other important "behind the scenes" 
administrative and support services provide an underlying base or 
foundation that makes the conveniences and necessities of modern 
life as we know it possible and efficient, and allow the wheels of 
5 commerce to spin smoothly. 

Suppose you want to buy bread at the local bakery. The 
baker doesn't have to do everything involved in making the bread 
because he can rely on support and administration services the 
community provides. For example: 
1 0 • The baker doesn't need to grow or mill grain to make 

flour for the bread. Instead, he can purchase flour from a 
supplier that delivers it by truck. 

• Similarly, the baker doesn't need to grow or produce fuel 
to keep its ovens hot; that fuel can be delivered in pipes 

1 5 or tanks by people who specialize in producing and 

supplying fuel. 

• You can also have confidence in the cleanliness of the 
local bakery because it displays an inspection notice 
certifying that it has been inspected by the local health 

20 department 

Support and administrative services are also very important 
to ensure that people are compensated for their efforts. For 
example: 

• You and the bakery can safely trust the government to 
25 stand behind the currency you take out of your wallet or 

purse to pay for the bread. 
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• If you pay by check, the banking system debits the 
amount of your check from your bank account overnight 
and gives the bakery the money. 

• If you and the bakery use different banks, your check 

5 may be handled by an automated "clearinghouse" system 

that allows different banks to exchange checks and settle 
accounts - efficiently transferring money between the 
banks and returning checks drawn on accounts that don't 
have enough money in them. 
10 • If the bakery accepts credit cards as payment, the 

flexibility of payment methods accepted in exchange for 
the bakery products is increased and provides increased 
convenience and purchasing power to its customers. 
Such support and administrative services provide great 
1 5 economies in terms of scale and scope - making our economy 
much more efficient. For example, these important support and 
administrative services allow the baker to concentrate on what he 
knows how to do best - make and bake bread. It is much more 
efficient for a bakery and its experienced bakers to make many 
20 loaves of bread in its large commercial ovens than it is for 

individual families to each bake individual loaves in their own 
home ovens, or for the growers of grain to also bake the bread and 
pump the fuel needed for baking and accept barter, for example, 
chickens in exchange for the bread. As a result, you and the 
25 bakery can complete your purchasing transaction with a credit 
card because both you and the bakery have confidence that such a 
payment system works well and can be trusted to "automatically" 

4 



function as a highly efficient and convenient basis for non-cash 
transactions. 

The Electronic Community Needs Administrative and Supp ort 
Services 

5 There is now a worldwide electronic community. Electronic 

community participants need the ability to shape, control, and, in 
an electronic world, automate, their interactions. They badly need 
reliable, secure, trusted support and administrative services. 

More and more of the world's commerce is being carried on 

10 electronically. The Internet — a massive electronic network of 
networks that connects millions of computers worldwide ~ is 
being used increasingly as the vehicle for commerce transactions. 
Fueled largely by easy-to-use interfaces (e.g., those allowing 
customers to "point and click'* on items to initiate purchase and 

1 5 then to complete a simple form to convey credit card information), 
the Internet is rapidly becoming a focal point for consumer and 
business to business purchases. It is also becoming a significant 
"channel" for the sale and distribution of all kinds of electronic 
properties and services, including information, software, games, 

20 and entertainment. 

At the same time, large companies use both private and 
public data networks to connect with their suppliers and 
customers. Driven by apparently inexorable declines in the cost of 
both computing power and network capacity, electronic commerce 

25 will increase in importance as the world becomes more and more 
computerized. This new electronic community ~ with its 
widespread electronic commerce - is generating great new 



demands for electronic administrative, support and "clearing" 
services. 

The electronic community badly needs a foundation that 
will support both commercial and personal electronic interactions 
and relationships. Electronic commerce on any significant scale 
will require a dependable, efficient, scaleable, and secure network 
of third party support and administrative service providers and 
mechanisms to facilitate important parts of the transaction process. 
For example: 

• People who provide value to the electronic community 
require seamless and efficient mechanisms allowing 
them to be compensated for the value they provide. 

• Providers who sell goods or services to the electronic 
community need reliable, efficient electronic payment 
mechanisms to service themselves and other value chain . 
participants. 

• Purchasers in the electronic marketplace, while often 
unaware of the behind-the-scenes intricacies of payment 
transaction activity, nonetheless require easy to use, 
efficient and flexible interfaces to payment mechanisms 
and financial obligation fulfillment systems. 

• Rights holders in all types of electronic "content" (for 
example, analog or digital information representing text, 
graphics, movies, animation, images, video, digital linear 
motion pictures, sound and sound recordings, still 
images, software computer programs, data), and to many 
types of electronic control processes, require secure, 
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flexible and widely interoperable mechanisms for 
managing their rights and administering their business 
models, including collecting, when desired, payments 
and relevant usage information for various uses of their 
5 content. 

• All parties require infrastructure support services that 
remain dependable, trusted, and secure even as the 
volume of commerce transactions increases, 
substantially. 

1 0 An important cornerstone of successful electronic 

transaction management and commerce is therefore the 
development and operation of a set of administrative and support 
services that support these objectives and facilitate the emergence 
of more diverse, flexible, scaleable, and efficient business models 

15 for electronic commerce generally. 

The Ginter Pat ent Specification Describes a Comnrehensive 
Solution 

The above-referenced Ginter, et al. patent specification 
describes technology providing unique, powerful capabilities 

20 instrumental to the development of secure, distributed transaction- 
based electronic commerce and rights management. This 
technology can enable many important, new business models and 
business practices on the part of electronic commerce participants 
while also supporting existing business models and practices. 

25 The Ginter et al. specification describes comprehensive 

overall systems and wide arrays of methods, techniques, structures 

and arrangements that enable secure, efficient distributed 

7 
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electronic commerce and rights management on the Internet (and 
Intranets), within companies large and small, in the living room, 
and in the home office. Such techniques, systems and 
arrangements bring about an unparalleled degree of security, 

5 reliability, efficiency and flexibility to electronic commerce and 
electronic rights management. 

The Ginter, et al. patent specification also describes an 
"Information Utility" - a network of support and administrative 
services, facilities and installations that grease the wheels of 

1 0 electronic commerce and support electronic transactions in this 
new electronic community. For example, Ginter, et al. details a 
wide array of support and administrative service providers for 
interfacing with and supporting a secure "Virtual Distribution 
Environment." These support and administrative service 

IS providers include: 

• transaction processors, 

• usage analysts, 

• report receivers, 

• report creators, 

20 • system administrators, 

• permissioning agents, 

• certification authority 

• content and message repositories, 
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• financial clearinghouses, 

• consumer/author registration systems, 

• template libraries, 

• control structure libraries, 
5 • disbursement systems, 

• electronic funds transfer, credit card, paper billing 
systems, and 

• receipt, response, transaction and analysis audit 
systems. 

10 The Present Inventions Build On and Extend the Solutions 
Described In the Ginter Patent Specification 

The present inventions build on the fundamental concepts 
described in the Ginter, et al. patent specification while extending 
those inventions to provide further increases in efficiency, 

1 5 flexibility and capability. They provide an overlay of distributed 
electronic administrative and support services (the "Distributed 
Commerce Utility"). They can, in their preferred embodiments, 
use and take advantage of the "Virtual Distribution Environment" 
(and other capabilities described in the Ginter et al patent 

20 specification and may be layered on top of and expand on those 
capabilities. 
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Brief Summary of S ome of the Features and Advantages of the 
Present Inventions 

The present inventions provide an integrated, modular array 
of administrative and support services for electronic commerce 
and electronic rights and transaction management. These 
administrative and support services supply a secure foundation for 
conducting financial management, rights management, certificate 
authority, rules clearing, usage clearing, secure directory services, 
and other transaction related capabilities functioning over a vast 
electronic network such as the Internet and/or over organization 
internal Intranets, or even in-home networks of electronic 
appliances. 

These administrative and support services can be adapted to 
the specific needs of electronic commerce value chains. 
Electronic commerce participants can use these administrative and 
support services to support their interests, and can shape and reuse 
these services in response to competitive business realities. 

The present inventions provide a "Distributed Commerce 
Utility" having a secure, programmable, distributed architecture 
that provides administrative and support services. The Distributed 
Commerce Utility can make optimally efficient use of commerce 
administration resources, and can scale in a practical fashion to 
accommodate the demands of electronic commerce growth. 

The Distributed Commerce Utility may comprise a number 
of Commerce Utility Systems. These Commerce Utility Systems 
provide a web of infrastructure support available to, and reusable 
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by, the entire electronic community and/or many or all of its 
participants. 

Different support functions can be collected together in 
hierarchical and/or in networked relationships to suit various 
5 business models and/or other objectives. Modular support 
functions can be combined in different arrays to form different 
Commerce Utility Systems for different design implementations 
and purposes. These Commerce Utility Systems can be 
distributed across a large number of electronic appliances with 
1 0 varying degrees of distribution. 

The comprehensive "Distributed Commerce Utility" 2 
provided by the present invention: 

• Enables practical and efficient electronic commerce and 
rights management 

15 • Provides services that securely administer and support 

electronic interactions and consequences. 

• Provides infrastructure for electronic commerce and 
other forms of human electronic interaction and 
relationships. 

20 • Optimally applies the efficiencies of modern distributed 

computing and networking. 

• Provides electronic automation and distributed 
processing. 

• Supports electronic commerce and communications 

25 infrastructure that is modular, programmable, distributed 

and optimally computerized. 
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Provides a comprehensive array of capabilities that can 

be combined to support services that perform various 

administrative and support roles. 

Maximizes benefits from electronic automation and 

distributed processing to produce optimal allocation and 

use of resources across a system or network. 

Is efficient, flexible, cost effective, configurable, 

reusable, modifiable, and general izable. 

Can economically reflect users' business and privacy 

requirements. 

Can optimally distribute processes — allowing commerce 
models to be flexible, scaled to demand and to match 
user requirements. 

Can efficiently handle a full range of activities and 
service volumes. 

Can be fashioned and operated for each business model, 
as a mixture of distributed and centralized processes. 
Provides a blend of local, centralized and networked 
capabilities that can be uniquely shaped and reshaped to 
meet changing conditions. 

Supports general purpose resources and is reusable for 
many different models; in place infrastructure can be 
reused by different value chains having different 
requirements. 

Can support any number of commerce and 
communications models; 
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Efficiently applies local, centralized and networked 
resources to match each value chain's requirements. 
Sharing of common resources spreads out costs and 
maximizes efficiency. 
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Supports mixed, distributed, peer-to-peer and centralized 
networked capabilities. 

Can operate locally, remotely and/or centrally. 

Can operate synchronously, asynchronously, or support 

both modes of operation. 
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Adapts easily and flexibly to the rapidly changing sea of 



commercial opportunities, relationships and constraints 
of "Cyberspace." 
In sum, the Distributed Commerce Utility provides 
comprehensive, integrated administrative and support services for 
1 5 secure electronic commerce and other forms of electronic 
interaction. 

Some of the advantageous features and characteristics of the 
Distributed Commerce Utility provided by the present inventions 
include the following: 
20 • The Distributed Commerce Utility supports 



programmable, distributed, and optimally computerized 



commerce and communications administration. It 



25 



uniquely provides an array of services that perform 
various administrative and support roles — providing the 
administrative overlay necessary for realizing maximum 
benefits from electronic automation, distributed 
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processing, and system (e.g., network) wide optimal 
resource utilization. 

The Distributed Commerce Utility is particularly adapted 
to provide the administrative foundation for the Internet, 
organization Intranets, and similar environments 
involving distributed digital information creators, users, 
and service systems. 

The Distributed Commerce Utility architecture provides 
an efficient, cost effective, flexible, configurable, 
reusable, and generalizable foundation for electronic 
commerce and communications administrative and 
support services. Providing these capabilities is critical 
to establishing a foundation for human electronic 
interaction that supports optimal electronic relationship 
models — both commercial and personal. 

• The Distributed Commerce Utility architecture 
provides an electronic commerce and communication 
support services foundation that can be, for any 
specific model, fashioned and operated as a mixture 
of distributed and centralized processes. 

• The Distributed Commerce Utility supported models 
can be uniquely shaped and reshaped to progressively 
reflect optimal blends of local, centralized, and 
networked Distributed Commerce Utility 
administrative capabilities. 
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The Distributed Commerce Utility's innovative 
electronic administrative capabilities support mixed, 
distributed, peer-to-peer and centralized networked 
capabilities. Collections of these capabilities, can 
each operate in any mixture of local, remote, and 
central asynchronous and/or synchronous networked 
combinations that together comprise the most 
commercially implementable, economic, and 
marketable — that is commercially desirable - model 
for a given purpose at any given time. 

The Distributed Commerce Utility architecture is 
general purpose. It can support any number of 
commerce and communication models which share 
(e.g., reuse), as appropriate, local, centralized, and 
networked resources. As a result, the Distributed 
Commerce Utility optimally enables practical and 
efficient electronic commerce and rights management 
models that can amortize resource maintenance costs 
through common usage of the same, or overlapping, 
resource base. 

One or more Distributed Commerce Utility commerce 
models may share some or all of the resources of one 
or more other models. One or more models may shift 
the mix and nature of their distributed administrative 
operations to adapt to the demands of Cyberspace — a 
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rapidly changing sea of commercial opportunities, 
relationships, and constraints. 

The Distributed Commerce Utility supports the 
processes of traditional commerce by allowing their 
translation into electronic commerce processes. The 
Distributed Commerce Utility further enhances these 
processes through its use of distributed processing, 
rights related "clearinghouse" administration, security 
designs, object oriented design, administrative smart 
agents, negotiation and electronic decision making " 
techniques, and/or electronic automation control 
techniques as may be necessary for efficient, 
commercially practical electronic commerce models. 

Certain Distributed Commerce Utility operations 
(financial payment, usage auditing, etc.) can be 
performed within participant user electronic appliance 
secure execution spaces such as, for example, 
"protected processing environments" disclosed in 
Ginter et al. 

Distributed clearinghouse operations may be 
performed through "virtually networked and/or 
hierarchical" arrays of Commerce Utility System sites 
employing a general purpose, interoperable (e.g., 
peer-to-peer) virtual distribution environment 
foundation. 
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For a given application or model, differing arrays of 
Distributed Commerce Utility Services may be 
authorized to provide differing kinds of 
administrative and/or support functions. 

Any or all of the roles supported by the Distributed 
Commerce Utility may be performed by, and/or used 
by, the same organization, consortium or other 
grouping of organizations, or other electronic 
community participants, such as individual user web 
sites. 

One or more parts of the Distributed Commerce 
Utility may be comprised of a network of distributed 
protected processing environments performing one or 
more roles having hierarchical and/or peer-to-peer 
relationships. 

Multiple Distributed Commerce Utility protected 
processing environments may contribute to the 
overall role of a service, foundation component, 
and/or clearinghouse. 

Distributed protected processing environments 
contributing to a Distributed Commerce Utility role 
may be as distributed, in a preferred embodiment, as 
the number of VDE participant protected processing 
environments and/or may have specific hierarchical, 
networked and/or centralized administration and 

17 
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support relationship(s) to such participant protected 
processing environments. 



In a given model, certain one or more Distributed 
Commerce Utility roles may be fully distributed, 
certain other one or more roles may be more (e.g., 
hierarchically), and/or fully, centralized, and certain 
other roles can be partially distributed and partially 
centralized. 

The fundamental peer-to-peer control capabilities 
provided by the Distributed Commerce Utility allows 
for any composition of distributed roles that 
collectively provide important, practical, scaleable, 
and/or essential commerce administration, security, 
and automation services. 

Combinations of Distributed Commerce Utility 
features, arrangements, and/or capabilities can be 
employed in programmable mixtures of distributed 
and centralized arrangements, with various of such 
features, arrangements, and capabilities operating in 
end-user protected processing environments and/or 
"middle" foundation protected processing 
environments (local, regional, class specific, etc.) 
and/or centralized service protected processing 
environments. 
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• The Distributed Commerce Utility is especially useful 
to support the Internet and other electronic 
environments that have distributed information 
creators, users and service providers. By helping 
people to move their activities into the electronic 
world, it plays a fundamentally important role in 
migration of these non-electronic human activities 
onto the Internet, Intranets, and other electronic 
interaction networks. Such network users require the 
Distributed Commerce Utility foundation and support 
services in order to economically realize their 
business and privacy requirements. This secure 
distributed processing foundation is needed to 
optimally support the capacity of electronic 
commerce models to meaningfully scale to demand 
and efficiently handle the full range of desired 
activities and service volume. 

• • The Distributed Commerce Utility technologies 
provided by the present inventions provide a set of 
20 secure, distributed support and administrative 

services for electronic commerce, rights management, 
and distributed computing and process control. 

• The Distributed Commerce Utility support services 
including highly secure and sophisticated technical 
25 and/or contractual services, may be invoked by 

electronic commerce and value chain participants in a 

19 
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seamless, convenient, and relatively transparent way 
that shields users against the underlying complexity 
of their operation. 

The Distributed Commerce Utility can ensure 
appropriately high levels of physical, computer, 
network, process and policy-based security and 
automation while providing enhanced, efficient, 
reliable, easy to use, convenient functionality that is 
necessary (or at least highly desirable) for orderly and 
efficiently supporting of the needs of the electronic 
community. 

The Distributed Commerce Utility, in its preferred 
embodiments, support the creation of competitive 
commercial models operating in the context of an 
"open" VDE based digital marketplace. 

The Distributed Commerce Utility can provide 
convenience and operating efficiencies to their value 
chain participants. For example, they may offer a 
complete, integrated set of important "clearing" 
function capabilities that are programmable and can 
be shaped to optimally support multi-party business 
relationship through one seamless, "distributed" 
interface (e.g., a distributed application). Clearing 
and/or support functions and/or sub-functions can, as 
desirable, be made available individually and/or 
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separately so as to serve business, confidentiality, 
efficiency, or other objectives. 

The Distributed Commerce Utility can make it easy 
for providers, merchants, distributors, repurposers, 
consumers, and other value chain participants to 
attach to, invoke, and work with Distributed 
Commerce Utility services. Hookups can be easy, 
seamless and comprehensive (one hook-up may 
provide a wide variety of complementary services). 

The Distributed Commerce Utility can further 
enhance convenience and efficiency by providing or 
otherwise supporting consumer brand images for 
clearing services offered by participant organizations, 
but utilizing shared infrastructure and processes. 

The Distributed Commerce Utility can realize 
important efficiencies resulting from scale and 
specialization by participant organizations by 
supporting "virtual" models that electronically and 
seamlessly employ the special services and 
capabilities of multiple parties. 

The Distributed Commerce Utility makes it possible 
for consumers to conveniently receive a benefit such 
as a service or product, where such service or product 
results from the invocation of a "fabric" of various 
support services — each of which service may be 

21 
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comprised of a distributed fabric of more specialized 
services and/or participating constituent service 
providers (the overall fabric is apparent to the value 
chain participant, the underlying complexity is (or 
can be) largely or entirely hidden). 

Distributed Commerce Utility services and 
capabilities in their preferred embodiments can 
employ and be combined in any reasonable manner 
with any one or more Virtual Distribution 
Environment capabilities described in Ginter, et. al., 
including for example: 

A. VDE chain of handling and control, 

B. secure, trusted internodal communication 
and interoperability, 

C. secure database, 

D. authentication, 

E. cryptographic, 

F. fingerprinting, 

G. other VDE security techniques, 

H. rights operating system, 

I. object design and secure container 
techniques, 

J. container control structures, 
K. rights and process control language, 
L. electronic negotiation, 
M. secure hardware, and 
22 



N. smart agent (smart object) techniques (for 
example, smart agents employed as process 
control, multi-party, and/or other 
administrative agent capabilities supporting 
5 distributed node administrative integration). 



Commerce Utility Systems Can Be Distributed and Combined 
The support and administrative service functions provided 
by the Distributed Commerce Utility can be combined in various 

1 0 ways and/or distributed through an electronic community, system 
or network. The preferred embodiment uses the protected 
processing environment based Virtual Distribution Environment 
described in Ginter et al. to facilitate such combinations and 
distributedness. Since all such Virtual Distribution Environment 

1 5 protected processing environments are at least to some degree 
trusted, every protected processing environment can be a 
clearinghouse or a part of a clearinghouse. Commerce models 
acceptable to the interest and desires of VDE commerce node 
users, can support Distributed Commerce Utility services that are 

20 pushed all the way to end-user electronic appliances employing, 
for example, other VDE protected processing environments, 
secure communication techniques and other VDE capabilities (as 
discussed elsewhere VDE capabilities can be directly integrated 
with the present inventions). Such appliances, along with more 

25 centralized value chain nodes can together form combinations that 
function as virtual clearing protected processing environments. In 
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the end, cyberspace will be populated, in part, by big, "virtual" 
computers where access to resources is based upon "availability" 
and rights. 

The Distributed Commerce Utility is a modular, 
programmable and generalizable context that it can support such 
virtual computers. The Distributed Commerce Utility is a unique 
architectural foundation for the design of electronic commerce 
value chain models and virtual computers. The programmable 
nature of a particular implementation can support differing actual 
(logical and/or physical), and/or degrees of, distribution for the 
same and/or similar services For example: 

• Centralized Commerce Utility Systems and services may 
be used to provide certain support service functions, or 
collections of functions, efficiently from a centralized 
location. 

• Other Commerce Utility Systems might be provided in a 
partially or wholly distributed manner. 

• Some support and administrative service functions might 
be distributed in and/or throughout existing or new 
communications infrastructure or other electronic 
network support components. 

• Other support services might operate within secure 
execution spaces (e.g., protected processing 
environments) on any or all user electronic appliances, 
using peer-to-peer communications and interactions, for 
example, to provide a secure web of support service 
fabric. 
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• Other support services might operate both in the network 

support infrastructure and at user electronic appliances. 
Such distributed support services may complement (and/or 
eliminate the need for) more centralized support service 
5 installations. Different combinations of the same and/or differing, 
non-distributed and differently distributed services may be 
provided to support different activities. Moreover, the nature and 
distribution of services for one overall model may differ from one 
implementation to another. Such differing model implementations 
1 0 can, if desired, share both the same Commerce Utility Systems and 
Services and/or any particular and/or any combination of 
Distributed Commerce Utility administrative and/or support 
functions. 

Further, a particular Commerce Utility Systems and Service 
1 5 infrastructure may be used by differing value chains (e.g., business 
model or relationship set) in differing manners. For example, 
certain value chains may elect to keep certain support service 
functions more centralized for efficiency, security, control or other 
reasons, others may elect more and/or differently distributed 
20 models. 

Provided that, for example, payment methods and 
rightsholders and/or other value chain participants concur, any one 
or more of the Distributed Commerce Utility secure infrastructure 
support services may distribute and/or delegate a portion or all of 
25 their functions and authority to any arbitrary collection or set of 
end-user and/or other value chain electronic appliances. 
Distributing and delegating these services and functions has 
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various advantages including, for example, enabling flexible and 
efficient creation of temporary, ad hoc webs of secure electronic 
commerce in which any, a number, or all appliance(s) in the 
collection or set may participate as at least a partial (if not full) 
5 peer of other appliances in the same commerce web fabric. 
The present invention provides the following non- 
exhaustive list of additional features relating to distributing 
administrative and support functions: 

• Any mixture of any administrative and/or support 

10 functions may be integrated with any other mixture of 

administrative and/or support functions. 

• Any set or subset of Commerce Utility System functions 
can be combined in an integrated design with any other 
mixture of Commerce Utility system functions. Such 

1 5 mixtures can be distributed to any desired degree and 

any one or more portions of the mixture may be more or 
less distributed than any other one or more portion. This 
allows a value chain to employ optimum desired and/or 
practical designs. Any mixture, including any degrees of 

20 distribution, of rights clearing, financial clearing, usage 

aggregation, usage reporting and/or other clearing and/or 
other Distributed Commerce Utility functions, can be 
provided. Such Distributed Commerce Utility functions 
and/or administrative and/or support services can be 

25 combined with any other desired Distributed Commerce 

Utility functions and/or administrative and/or support 
services. 
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• Any one or more such administrative and/or support 
services and/or functions can operate as a Commerce 
Utility System and support a web of Commerce Utility 
System nodes, each of which supports at least a portion 
of such Commerce Utility administrative service 
activities. Each Commerce Utility System may be 
capable of granting authority and/or providing services 
to and/or otherwise securely interoperating with other 
Commerce Utility Systems and/or nodes. 

• Each Commerce Utility System (or combination of 
Commerce Utility Systems) may be capable of 
participating as a "virtual clearinghouse" comprised of 
plural Commerce Utility Systems. In the preferred 
embodiment, these "virtual clearinghouses" may, when 
in accordance with VDE rules and controls, interoperate 
— in a fashion prescribed by such rules and controls ~ 
with other Commerce Utility Systems and/or other 
virtual clearinghouses participating in the same web. 
Such "virtual clearinghouses" may receive authority 
from secure chain of handling and control embodied in 
electronic control sets, and may participate in electronic 
commerce process automation resulting from such chain 
of handling and control and other VDE capabilities. 

This ability to distribute, and, if desired to subsequently 
adapt (modify), any support service functions to any desired 
degree across a system or network provides great power, 
flexibility and increases in efficiency. For example, distributing 
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aspects of support services such as clearing functions will help 
avoid the "bottlenecks" that a centralized clearing facility would 
create if it had insufficient capacity to handle the processing loads. 
Taking advantage of the distributed processing power of many 
5 value chain participant appliances also has great benefits in terms 
of improved effectiveness and system response time, much lower 
overhead of operation, greater fault tolerance, versatility in 
application implementations, and, in general much greater value 
chain appeal resulting from the present inventions adaptability to 
1 0 each value chain participant's needs and requirements. 

Some Examples of Administrative and/or Support Services 
Provided bv the Distributed Commerce Utility 

The Distributed Commerce Utility may be organized into a 
number of different, special and/or general purpose "Commerce 

1 5 Utility Systems." The Commerce Utility Systems can be 
centralized, distributed, or partially distributed and partially 
centralized to provide administrative, security, and other services 
that practical commerce management layer requires. Certain 
Commerce Utility Systems comprise Distributed Commerce 

20 Utility implementations of certain well known administrative 
service functions, such as financial clearinghouse and certifying 
authorities. Other Commerce Utility Systems involve new forms 
of services and new combinations and designs for well known 
service activities. A Commerce Utility System is any 

25 instantiation of the Distributed Commerce Utility supporting a 

specific electronic commerce model, and a Commerce Utility 

System may itself be comprised of constituent Commerce Utility 
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Systems. Commerce Utility Systems may include any or all of the 
following, in any combination of capabilities and distribution 
designs, for example: 

• financial clearinghouses, 

5 • usage clearinghouses, 

• rights and permissions clearinghouses, 

• certifying authorities, 

• secure directory services, 

• secure transaction authorities, 

10 • multi-purpose, general purpose and/or combination 

Commerce Utility Systems including any 
combination of the capabilities of the systems listed 
immediately above, and 

• other Commerce Utility Systems. 

1 5 These Commerce Utility Systems are far-reaching in their 
utility and applicability. For example they may provide 
administrative support for any or all of the following: 

• trusted electronic event management, 

• networked, automated, distributed, secure process 
20 administration and control, 

• Virtual Distribution Environment chain-of- handling and 
control, arid 

• rights administration and usage (e.g., event) management 
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(e.g., auditing, control, rights fulfillment, etc.), across 
and/or within electronic networks, including 
"unconnected," virtually connected, or periodically 
connected networks. 
5 The Commerce Utility Systems may govern electronic process 
chains and electronic event consequences related to, for example: 

• electronic advertising, 

• market and usage analysis, 

• electronic currency, 

10 • financial transaction clearing and communications, 

• manufacturing and other distributed process control 
models, 

• financial clearing, 

• enabling payment fulfillment or provision of other 

1 5 consideration (including service fees, product fees or any 

other fees and/or charges) based at least in part on 
content, process control (event) and/or rights 
management, 

• performing audit, billing, payment fulfillment (or 

20 provision of other consideration) and/or other clearing 

activities, 

• compiling, aggregating, using and/or providing 
information relating to use of one or more secure 
containers and/or content and/or processes (events), 

25 including contents of secure containers and/or any other 

content, 

• providing information based upon usage auditing, user 
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profiling, and/or market surveying related to use of one 
or more secure containers and/or content and/or 
processes (events), 

employing information derived from user exposure to 
content (including advertising) and/or use of processes 
(events), 

providing object registry services; and/or rights, 
permissions, prices, and/or other rules and controls 
information; for registered and/or registering objects; 
electronically certifying information used with and/or 
required by rules and controls, such as authenticating 
identity, class membership and/or other attributes of 
identity context including for example, certification of 
class identity for automating processes, such as rights 
related financial transaction fulfillment based upon 
governing jurisdiction (taxation(s)), employment and/or 
other group membership including, for example, 
acquired class rights (e.g., purchased discount buyers 
club membership); 

third party archiving and/or authenticating of 
transactions and/or transaction information for secure 
backup and non-repudiation, 
providing programmed mixed arrays of Commerce 
Utility System process control and automation services, 
where different Commerce Utility Systems support 
different value chains and/or business models 
requirements, and where such Commerce Utility 
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Systems further support distributed, scaleable, efficient 
networked and/or hierarchical fixed and/or virtual 
clearinghouse models which employ secure 
communication among a Commerce Utility System's 
distributed clearinghouse protected processing 
environments for passing clearinghouse related rules and 
controls and derived, summarized, and/or detailed 
transaction information, 
EDI, electronic trading models, and distributed 
computing arrangements where participants require 
trusted foundation that enables efficient, distributed 
administration, automation, and control of transaction 
value chains, and 

other support and/or administrative services and/or 
functions. 

BRIEF DESCRIPTION OF THE DRAWINGS 

These and other features and advantages provided by the 
present inventions will become better and more completely 
20 understood by studying the following detailed description of 

presently preferred example embodiments in conjunction with the 
drawings, of which: 

Figure 1 shows an example Distributed Commerce Utility 
supporting a consumer's example electronic appliance; 
25 Figure 1 A shows a protected processing environment(s) 

("PPE") within the consumer's electronic appliances); 
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Figure IB shows that the Distributed Commerce Utility may 
comprise a number of example Commerce Utility Systems; 

Figures 2A-2E show examples of how administrative and 
support service functions can be distributed; 
5 Figures 3A-3C show example distributed Commerce Utility 

Systems; 

Figure 4 shows an example web of Commerce Utility 
Systems; 

Figure 4A shows a limitless web of consumer appliances 
1 0 and Commerce Utility Systems; 

Figure 5 shows how rights holders can select between 
multiple Commerce Utility Systems connected to an electronic 
"information highway"; 

Figure 6 shows an example of how different Commerce 
1 5 Utility Systems can work together; 

Figure 7 shows an example of how multiple administrative 
and support service functions can be combined and integrated 
within Commerce Utility Systems; 

Figure 7 A shows an example web of combined function 
20 Commerce Utility Systems; 

Figures 8A-8B show example Commerce Utility System 
hierarchies; 

Figure 9 shows an example hierarchy of multi- function 
Commerce Utility Systems 
25 Figure 10 shows an example financial clearinghouse; 

Figure 1 1 shows an example usage clearinghouse; 
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Figure 12 shows an example rights and permissions 
clearinghouse; 

Figure 13 shows an example certifying authority; 

Figure 14 shows an example secure directory service; 
5 Figure 1 5 shows an example transaction authority; 

Figures 16A-16F show that Commerce Utility Systems can 
support other commerce utility systems; 

Figures 17A through 17D-3 show an example Commerce 
Utility System architecture; 
1 0 Figure 1 7E- 1 through 1 7E-4 show Commerce Utility 

System example interaction models; 

Figure 17F shows an example arrangement for distributing 
portions of administrative and support service operations; 

Figure 1 8 shows an example financial clearinghouse 
15 Commerce Utility System; 

Figure 19 shows an example financial clearinghouse 
arrangement; 

Figure 20 shows an example financial clearing process; 
Figures 20A-20F show an additional example of financial 
20 clearing activities and processes; 

Figure 21 shows a simplified value chain (payment) 
disaggregation example; 

Figure 22 shows an example of how the Figure 21 
disaggregation can be implemented within a financial 
25 clearinghouse context; 
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Figure 22A shows an example arrangement for 
implementing payment disaggregation on a user protected 
processing environment; 

Figure 23 shows a more complex value chain (payment) 
disaggregation example; 

Figure 24 shows an example of how disaggregation can be 
implemented within a financial clearinghouse context; 

Figure 25 shows a value chain disaggregation example that 
also details compensation to the Distributed Commerce Utility; 

Figure 26 shows an example value chain (payment) 
disaggregation to any number of payees; 

Figure 27 shows an additional example of how value chain 
(payment) disaggregation and redistribution may be accomplished 
through a financial clearinghouse; 

Figure 28 shows an example superdistribution payment and 
redistribution scenario using a financial clearinghouse for 
financial clearing; 

Figure 29 shows an example value chain (payment) 
aggregation at a consumer protected processing environment or 
other site; 

Figure 30 shows example value chain (payment) 
aggregation across multiple transactions; 

Figure 3 1 shows example value chain (payment) 
aggregation across multiple transactions and multiple consumers; 

Figure 32 shows an example Commerce Utility System 
architecture providing payment aggregation; 
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Figure 33 shows an example usage clearinghouse 
Commerce Utility System; 

Figure 34 shows an example usage clearinghouse 
architecture; 

5 Figure 35 shows an example usage clearing process; 

Figure 36 shows an additional example usage clearing 
process using multiple usage clearinghouses; 

Figure 37 shows an example usage clearing process using 
usage and financial clearinghouses; 
10 Figure 38 shows an example usage clearinghouse media 

placement process; 

Figure 39 shows an example usage clearing process 
providing discounts based on different levels of consumer usage 
information disclosure; 
1 5 Figure 40 shows an example rights and permissions 

clearinghouse Commerce Utility System; 

Figure 41 shows an example rights and permissions 
clearinghouse architecture; 

Figure 42 shows an example rights and permissions clearing 
20 process; 

Figure 42A shows an example control set registration 
process for updates; 

Figure 43 shows an additional example rights and 
permissions clearing process; 
25 Figures 44A - 44E show an additional rights and 

permissions clearing example; 
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Figures 45A and 45B show example rights template(s); 
Figure 45C shows an example control set corresponding to 
the example rights template(s); 

Figure 46 shows another example rights and permissions 
clearing process; 

Figure 47 shows an example certifying authority Commerce 
Utility System; 

Figure 48 shows an example certifying authority 
architecture; 

Figure 49 shows an example certifying process; 
Figure 50 shows an example distributed certifying process; 
Figure 50A shows an example control set that conditions 
performance and/or other consequences on the presence of digital 
certificates; 

Figures 51A-51D show example digital certificate data 
structures; 

Figure 5 IE shows an example technique for generating 
digital certificates based on other digital certificates and a trusted 
database(s); 

Figures 51F-51H show an example technique for defining a 
virtual entity; 

Figure 52 shows an example secure directory services 
Commerce. Utility System; 

Figure 53 shows an example secure directory services 
architecture; 

Figure 54 shows an example secure directory services 
process; 
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Figure 55 shows an example transaction authority 
Commerce Utility System; 

Figure 56 shows an example transaction authority 
architecture; 

5 Figure 57 shows an example transaction authority process; 

Figure 58A shows an example of how the transaction 
authority creates a control superset; 

Figure 58B shows example steps performed by the 
transaction authority; 
1 0 Figures 58C and 58D show an example secure checkpoint 

Commerce Utility System; 

Figures 59 and 60 show examples of how the Distributed 
Commerce Utility can support different electronic value chains; 
Figure 61 shows a purchase, licensing and/or renting 
1 5 example; 

Figure 62 shows a tangible item purchasing and paying 
example; 

Figure 63 shows an example of a customer securely paying 
for services; 

20 Figure 64 shows example value chain disaggregation for 

purchase of tangibles; 

Figure 65 shows an example of cooperation between 
Commerce Utility Systems internal and external to an 
organization; 

25 Figure 66 shows an example inter and intra organization 

transaction authority example; 
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Figure 67 shows an international trading example. 

DETAILED DESCRIPTION OF EXAMPLE 
EMBODIMENTS 

Distributed Commerce Utility 

5 Figure 1 shows an example consumer appliance 1 00 

electronically connected to Distributed Commerce Utility 75. In 
this example, an electronic network 150 connects appliance 100 to 
Distributed Commerce Utility 75. Distributed Commerce Utility 
75 supports the activities going on within consumer appliance 
10 100. 

Distributed Commerce Utility 75 provides a foundation of 
administrative and support services for electronic commerce and 
communications. This foundation is efficient, cost effective, 
flexible, configurable, reusable, programmable and generalizable. 
1 5 It supports all kinds of electronic relationships, interactions and 
communications for both personal and business use. 

The Distributed Commerce Utility Can Support Anv 
Electronic Appliance 

Appliance 100 may be any sort of electrical or electronic 

20 device such as for example, a computer, an entertainment system, 

a television set, or a video player - just to name a few examples. 

In the particular example shown in Figure 1, the consumer 

appliance 100 is a home color television set 1 02, a video 

player/recorder 104, and a set top box 106. Appliance 100 may be 

25 controlled by hand held remote controller 108, for example. Set 

top box 106 could receive television programs from television 
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broadcasters 1 10 and/or satellites 1 12 via a cable television 
network 1 14, for example. Player/recorder 104 could play various 
types of program material from tapes, optical disks or other media, 
and may also have the capability of recording program materials 
5 received through set top box 1 06. 

The Appliance 100 Can Have A "Protected Processing 
Environment" 

Appliance 100 preferably is a secure electronic appliance of 
the type shown for example in Figures 7 and 8 of the Ginter et al. 

10 patent specification. It is preferably part of the "Virtual 

Distribution Environment" described in the Ginter, et al. patent 
specification. Figure 1 A shows that television 102, set top box 
106, media player/recorder 104 and remote control 108 may each 
have a "protected processing environment" ("PPE") 1 54. 

15 Distributed Commerce Utility 75 may interact with and support 
the processes going on within each of these protected processing 
environments 154. 

Protected processing environments 154 may be based on 
one or more computer chips, such as a hardware and/or software 

20 based "secure processing unit" as shown in Figure 9 of the Ginter 
et al. Patent specification. The protected processing environment 
1 54 provides a highly secure, trusted environment in which 
electronic processes and transactions can be reliably performed 
without significant danger of tampering or other compromise. The 

25 Ginter et al. patent disclosure describes techniques, systems and 

methods for designing, constructing and maintaining the protected 

processing environment 1 54 so that rights holders and other value 
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chain participants (including consumers 95) can trust its security 
and integrity. In the preferred embodiment, this trustedness is 
important in the interaction between the Distributed Commerce 
Utility 75 and electronic appliance 100. 

The Distributed Commerce Utility Can be Made Up of Many 
"Commerce Utility Systems" 

Figure IB shows that Distributed Commerce Utility 75 can 
be made up of a number of Commerce Utility Systems 90. There 
can be different kinds of Commerce Utility Systems, for example: 

• a financial clearinghouse 200; 

• a usage clearinghouse 300; 

• a rights and permissions clearinghouse 400; 

• a certifying authority 500; 

• a secure directory services 600; 

• a transaction authority 700; 

• a VDE administrator 800; and 

• other kinds of Commerce Utility Systems 90. 

Commerce Utility Systems 90 can support and administer 
functions or operations within protected processing 
environments) 154. For example: 

• The appliance 1 00 protected processing environment 

154 may provide an automatic electronic payment 

mechanism 1 1 8 that debits the consumers* bank or 

other money account based on program consumption. 

Distributed Commerce Utility 75 may include a 
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special purpose Commerce Utility System 90a called 
a "financial clearinghouse" 200 that supports 
financial aspects of the operation of the protected 
processing environment 154 — ensuring that rights 
holders and others get paid appropriate amounts and 
that the consumers 95 are not charged excessive 
amounts. 

The broadcaster of a television program 102a may 
require appliance 100's protected processing 
environment 1 54 to meter, with an electronic usage 
metering mechanism 116, how much of video 
program 102a the consumers 95 watch, and which 
video programs they watch. Distributed Commerce 
Utility 75 may include a special purpose Commerce 
Utility System 90b called a "usage clearinghouse" 
300 that receives usage information metered by a 
usage meter 1 16 within the protected processing 
environment 1 54, analyzes it and provides reports. 

The rights holders in video program 1 02a may insist 
upon the protected processing environment 154 
providing a copy protection mechanism 120 that 
securely protects against copying video program 
102a. Distributed Commerce Utility 75 may include 
a special purpose Commerce Utility System 90c 
called a "rights and permissions clearinghouse" 400 
that supplies the protected processing environment 
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154 with necessary permissions to allow consumers 
95 to watch particular programs (for example, on a 
pay per view basis) and to assist in enforcing 
prohibitions, such as, for example, a copy protection 
mechanism 120. 

• Rights holders in video program 1 02a may further 
require the appliance 1 00 protected processing 
environment 154 to possess a "digital certificate" 122 
certifying the consumer's identity, age, or the like 
before consumers 95 can watch video program 1 02a. 
Distributed Commerce Utility 75 may include a 
special purpose Commerce Utility System 90d called 
a "certifying authority" 500 that creates and provides 
"digital certificates" 504 to the protected processing 
environment 1 54 — allowing the consumers to 
efficiently interact with the permissions provided by 
the rights holders. 

Other Commerce Utility Systems 90 shown in Figure IB 
include: 

• A "Secure directory services" 600 that may assist the 
protected processing environment 154 in 
communicating electronically with other computers 
and appliances over network 1 50; 

• A "transaction authority" 700 that may be available 
for process control and automation such as, for 
example, securely auditing and overseeing 
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complicated electronic transactions involving 
protected processing environment 154; and 

• A virtual distribution environment ("VDE") 
"administrator" 800 that may, in the preferred 
5 embodiment, keep the protected processing 

environment 1 54 operating smoothly and securely. 

Still other Commerce Utility Systems 90 not shown in 
Figure IB may be used to administer and/or support additional 
functions and operations. The various Commerce Utility Systems 
1 0 90 can work together, dividing up the overall tasks to support the 
consumers 95 efficiently and effectively. 

Commerce Utility Systems Can Be Distributed 

Figures 2A-2E show how Distributed Commerce Utility 75 
can be distributed. Some administrative and support functions of 
1 5 Commerce Utility Systems 90 can be performed within a 

consumer's electronic appliance 100 - or even in a "spread out" 
fashion over a large number of different appliances cooperating 
together. 

As described above, appliances 100 each provide a 

20 protected processing environment 1 54 that is tamper resistant and 

provides a secure place in which administrative and support 

operations can be performed. This allows an electronic appliance 

100 within a consumer's home to perform operations that can 

trusted by other parties, such as rights holders, electronic 

25 commerce participants, and the like. Because of the trusted, 

protected characteristics of protected processing environment 1 54, 
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the parts, extensions or even the entirety of a Commerce Utility 
System 90 may exist within each or any of the protected 
processing environments 154 and associated electronic appliances 
within the overall system. 
5 Figures 2A-2E represent the overall functions of an example 

Commerce Utility System 90 such as Usage Clearinghouse 300 as 
a four-piece jigsaw puzzle. Figures 2A-2E show that these 
Commerce Utility System functions can be distributed to varying 
degrees. For example: 
10 • Figure 2A shows an example in which all functions of 

the Commerce Utility System 90 are performed in a 

secure central facility. 

• Figure 2B shows an example in which most functions of 
the Commerce Utility System 90 are performed in a 

1 5 secure central facility, but some of its functions are 

performed within the protected processing environment 
154 of a user electronic appliance 100. 

• Figure 2C shows an example in which some functions of 
the Commerce Utility System 90 are performed in a 

20 secure central facility, but most of its functions are 

performed within the protected processing environment 
154 of a user electronic appliance 100. 

• Figure 2D shows an example in which some functions of 
the Commerce Utility System 90 are performed in a 

25 secure central facility, some of its functions are 

performed within the protected processing environment 
1 54A of a first user electronic appliance 1 00A, and some 
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of its functions are performed within the protected 
processing environment 1 54B of a second user electronic 
appliance 100B. 
• Figure 2E shows an example in which none of the 
functions of the Commerce Utility System 90 are 
performed in a secure central facility; some of its 
functions are performed within the protected processing 
environment 1 54(1 ) of a first user electronic appliance 
100(1), some of its functions are performed within the 
protected processing environment 154(2) of a second 
user electronic appliance 100(2), ), some of its functions 
are performed within the protected processing 
environment 154(3) of a third user electronic appliance 
10 0(3), and some of its functions are performed within 
the protected processing environment 154(N) of a Nth 
user electronic appliance 100(N). 
Alternately or in addition, some of the functions of the 
Commerce Utility System 90 may be distributed within network 
1 50 - for example, in the equipment used to communicate data 
between appliances 100. 

Distributing Multiple Administrative and Support Functions 

Figure 3A shows how multiple Commerce Utility System 
90 functions or sub-functions can be distributed into the same 
protected processing environment 154. 

For example: 
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• Financial clearinghouse function 200a operating 
within consumer appliance lOOA's protected 
processing environment 1 54a may provide certain 
financial clearing such as auditing that can take the 
place of and/or support some of the financial clearing 
operations performed by a centralized financial 
clearinghouse 200. 

• Usage clearinghouse function 300a operating within 
consumer appliance lOOA's protected processing 
environment 1 54a may perform certain usage 
information clearing operations, such as, for example, 
combining or analyzing collected usage information 
to complement, substitute for, or add to usage 
clearing operations performed by usage clearinghouse 
300. 

• Appliance lOOA's protected processing environment 
1 54a may perform certain rights and permissions 
clearing operations 400a, certain certifying authority 
operations 500a, and certain secure directory services 
support operations 600a all at the consumer's site to 
complement, add to or substitute for operations 
performed by rights and permissions clearinghouse 
400, certifying authority 500 and secure directory 
services 600. 

Figure 3B shows that another example consumer electronic 
iances 100(2),..., 100N(in this case personal computers 124) 
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might perform different combinations of support or administrative 
functions locally (for example, some or all of the functions 
performed by transaction authority 700). For example: 

• the processes within protected processing environment 
1 54(1 ) may rely on a partially distributed and partially 
centralized financial clearinghouse 200 A, a partially 
distributed and partially centralized usage clearinghouse 
300A, a partially distributed and partially centralized 
rights and permissions clearinghouse 400A, a partially 
distributed and partially centralized certifying authority 
500A, a centralized secure directory services 600A, and 
a centralized transaction authority 700A; 

• the processes within protected processing environment 
154(2) may rely on a centralized financial clearinghouse 
200B, a partially distributed and partially centralized 
usage clearinghouse 300B, a partially distributed and 
partially centralized rights and permissions 
clearinghouse 400B, a centralized certifying authority 
500B, a centralized secure directory services 600B, and a 
partially distributed and partially centralized transaction 
authority 700B; and 

• the processes within protected processing environment 
154(N) may rely on a partially distributed and partially 
centralized financial clearinghouse 200N, a partially 
distributed and partially centralized usage clearinghouse 
300N, a partially distributed and partially centralized 
rights and permissions clearinghouse 400N, a partially 
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distributed and partially centralized certifying authority 
500N, a partially distributed and partially centralized 
secure directory services 600N, and a partially 
distributed and partially centralized transaction authority 
700N. 

Taking this concept of distributed clearing services further, 
it would be possible to completely distribute the Distributed 
Commerce Utility 75 as shown in Figure 3C - relying mostly or 
completely on administrative and support service operations and 
activities within the secure, protected processing environments 
154 of users' electronic appliances 100. Thus, the users' own 
electronic appliances 1 00 could - in a distributed manner - 
perform any or all of financial, usage, and rights and permissions 
clearing, as well as certification, secure directory services and 
transaction authority services. Such "local" and/or parallel and/or 
distributed processing transaction clearing might more efficiently 
accommodate the needs of individual consumers. For example, 
this is one way of allowing consumers to contribute controls that 
prevent certain private data from ever leaving their own electronic 
appliance while nevertheless providing rightsholders with the 
summary information they require. 

The distributed arrangements shown in Figures 2A-2E and 
3A-3C are not mutually exclusive ways of providing centralized 
Commerce Utility System 90. To the contrary, it may be 
advantageous to provide hybrid arrangements in which some 
administrative and support service functions (such as, for example, 
micro-payment aggregation, usage data privacy functions, and 
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some issuing of certificates, such as parents issuing certificates for 
their children) are widely distributed while other administrative 
and support service functions (for example, issuance of important 
digital certificates, maintaining massive data bases supporting 
secure directory services, etc.) are much more centralized. The 
degree of distributedness of any particular administrative and 
support service, clearinghouse or function may depend on a 
variety of very important issues including, for example, efficiency, 
trustedness, scalability, resource requirements, business models, 
and other factors. In addition, the degree of distribution may 
involve multiple levels of hierarchy based, for example, on sub- 
sets determined by specific business models followed by specific 
business sub-models, or, for example, geographic and/or 
governing body and/or region areas. 

Since a given electronic appliance 100 can participate in 
multiple activities, it is possible that its different activities may 
rely on different blends of distributed and centralized Commerce 
Utility Systems 90. For example, for one activity a protected 
processing environment 154 may rely on a centralized financial 
clearinghouse 200, for another activity it may rely on a partially 
distributed and partially centralized financial clearinghouse 200, 
and for still another activity it may rely on a wholly distributed 
financial clearinghouse 200. Different degrees of distributedness 
may be used for different activities or business models. 
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Web of Commerce Utility Systems 

Figure 4 shows that Commerce Utility System 75 may 
comprise a vast "web" of distributed, partly distributed and/or 
centralized Commerce Utility Systems 90. Network 150 can be 
used to connect this web of Commerce Utility Systems 90 to a 
variety of different electronic appliances 100 that can all share the 
Distributed Commerce Utility 75. For example, electronic 
network 150 can connect to: 

• set top boxes 1 06 and/or media players 1 04, 

• personal computers 124, 

• computer graphics workstations 126, 

• multi-media/video game systems 128, or 

• any other kinds of electronic appliances 100 
including for example, manufacturing control device, 
household appliances, process control equipment, 
electronic networking and/or other communication 
infrastructure devices, mainframe and/or mini 
computers, etc. 

In this example, the same Distributed Commerce Utility 75 
can support a variety of different kinds of activities of a number of 
different consumers, authors, distributors, providers, merchants, 
and other people - and the Distributed Commerce Utility 75 can 
support a very large variety of different electronic activities. 
Figure 4 also shows that Commerce Utility Systems 90 may 
communicate with electronic appliances 100 (and with each other) 
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by exchanging electronic "containers" 152 of the type disclosed in 
Ginter et al. for purposes of security (for example, secrecy, 
authenticity and integrity) and managed through the use of secure 
rules and controls processed in protected processing environments. 

5 The Commerce Utility Systems Web Can Be Virtually 
Limitless 

Figure 4A shows that the web of Commerce Utility Systems 
may be vast or limitless. Indeed, network 1 50 may be a seamless 
web stretching around the world and connecting millions upon 

1 0 millions of electronic appliances with any number of Commerce 
Utility Systems 90. 

The Commerce Utility Systems 90 web may provide a very 
complex interconnection with a variety of different types of 
electronic appliances performing a variety of different electronic 

1 5 functions and transactions. As mentioned above, any of electronic 
appliances 100 may be able to communicate with any of the 
Commerce Utility Systems 90 or with any other electronic 
appliance. This allows maximum efficiency and flexibility in 
terms of allocating different Commerce Utility Systems to 

20 different electronic transactions. For example: 

• Geographically close Commerce Utility Systems might 
best be used to minimize the amount of time it takes to 
get messages back and forth. 

• In some cases, more distant Commerce Utility Systems 
25 might be better equipped to efficiently handle certain 

kinds of specialized transactions. 
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• Government regulations might also, at least in part, 
dictate the selection of certain Commerce Utility 
Systems over others, (for example, a Japanese customer 
may run into legal problems if she tries to use a financial 

5 clearinghouse 200 located in the Cayman Islands - or a 

New Jersey resident might be required by law to deal 
with a financial clearinghouse 200 that reports New 
Jersey sales tax). 

• Different, competitive Commerce Utility Systems are 
1 0 likely to be offered by different parties and these 

different systems would populate the web comprising 
Distributed Commerce Utility 75. Interoperability 
between such System and/or their nodes is important for 
efficiency and to allow reusability of electronic 
15 commerce resources. 

Rights Holders And Providers Can Choose Among Commerce 
Utility Systems 

Figure 5 shows how rights holders can select between 

different Commerce Utility Systems 90. In this example, Bob 

20 operates a first usage clearinghouse 300a, Alice operates a second 

usage clearinghouse 300b, and Helen operates a third usage 

clearinghouse 300c. These various usage clearing service 

providers may compete with one another based on quality and/or 

price, or they may be complementary (for example, they may each 

25 specialize in different kinds of transactions). 

Because electronic network 150 may connect electronic 

appliances 100 to many different Commerce Utility Systems 90, 
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rightsholders in the digital properties the consumers are using may 
have a number of different Commerce Utility Systems to choose 
from. Content providers and rights holders may authorize 
particular (or groups of) Commerce Utility Systems 90 to handle 
5 different aspects of transactions. For example: 

• Computer software distributor might specify that a 
personal computer 124 should send metering 
information 1 16a to Helen's usage clearinghouse 
300c for monitoring usage of the computer software 

1 0 or other activities performed by the personal 

computer. 

• A rights holder in video program 1 02a might specify 
that set top box 106 should send metering information 
1 16 about the video to Alice's usage clearinghouse. 

15 • A multimedia content provider might specify that 

Bob's usage clearinghouse 300a should be used for 
processing usage data 1 16c generated by multimedia 
player 128. 

In some instances, particular consumers 95 may also pay a 
20 role in specifying in advance particular clearinghouses or other 
Commerce Utility Systems 90 they prefer to use. Figure 5 
illustrates the provider's (and/or consumer's) choice by a 
policeman directing metering traffic to selected usage 
clearinghouses 300 (electronic controls as described herein and in 
25 Ginter et al. would preferably be the mechanism actually 
controlling how traffic is directed). 
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A content provider or rights holder could allow a consumer 
95 to select from a group of Commerce Utility Systems 90 (and/or 
Commerce Utility Systems 90 providers) the content 
provider/rights holder wants to deal with. For example: 

• A television studio might authorize specific individual or 
classes of Commerce Utility Systems 90 to handle 
transactions relating to its television programs and/or it 
may specify particular individual or classes of 
Commerce Utility Systems 90 that it doesn't want to 
have handle its transactions. 

• Particular Commerce Utility Systems 90 may set 
requirements or standards for individual (or classes of) 
providers and/or consumers 95. 

• Value chain participants could enter into legal 
agreements and/or business relationships with different 
Commerce Utility Systems 90. 

Commerce Utility Systems Can Work Together 

Figure 6 shows that different Commerce Utility Systems 90 
can work together to support different kinds of operations. In this 
example: 

• Usage clearinghouse 300a, rights and permissions 
clearinghouse 400a, certifying authority 500a, and 
financial clearinghouse 200a (left-hand side of 
drawing) might be used to support a particular 
operation by set top box 106 and television set 1 02. 
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• The same financial clearinghouse 200a but a different 
usage clearinghouse 300b, a different certifying 
authority 500b and a different rights and permissions 
clearinghouse 400b (top of drawing) might be used to 

5. support certain activities on personal computer 124. 

• A still different financial clearinghouse 200c, 
certifying authority 500c and usage clearinghouse 
300c but the same rights and permissions 
clearinghouse 400b (right-hand side of drawing) 

' 0 might be used to support electronic activities of 

multimedia system 128. 

• A still different combination of Commerce Utility 
Systems (in this example, usage clearinghouse 300c, 
financial clearinghouse 200d, rights and permissions 

1 5 clearinghouse 400c and certifying authority 500a ~ 

along the bottom of the drawing) might be used to 
support sound system 130. 

This example shows that various Commerce Utility Systems 
90 may operate in combination, and that different combinations of 
20 Commerce Utility Systems might be used to support different 
electronic transactions. 

Administrative and Support Service Functions Can Be 
Combined Within General Purpose Commerce Utility Systems 
For Efficiency or Convenience 

25 Figure 7 shows that different special purpose Commerce 

Utility Systems 90 administrative and support service functions or 
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sub-functions may be integrated together into more general or 
multi-purpose Commerce Utility Systems 90 for maximum 
convenience, efficiency or other reasons. For example: 

• Bob may operate an integrated or combined 
Commerce Utility System 90a providing a financial 
clearinghouse 200a function, a certifying authority 
500a function, and a usage clearinghouse 300a 
function. 

• Anne may operate an integrated or combined 
Commerce Utility System 90b providing a financial 
clearinghouse function 200b, a rights and permissions 
clearinghouse function 400b and a transaction 
authority function 700b. 

• Helen may operate an integrated or combined 
Commerce Utility System 90c providing a rights and 
permissions clearinghouse function 400c and a 
certifying authority function 500c. 

• Roger may operate an integrated or combined 
Commerce Utility System 90d providing secure 
directory services 600d, usage clearinghouse services 
300d, financial clearinghouse services 200d and 
rights and permissions clearinghouse 400d. 

A consumer operating electronic appliances 100 may access 
any or all of these different Commerce Utility Systems 90 or 
combinations. For example, set top box 106 might obtain rights 
and permissions and certificates from Helen's Commerce Utility 
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System 90c, but might make use of Bob's Commerce Utility 
System 90a for financial clearing and usage analysis. 

A Commerce Utility System 90 may provide any 
combination of administrative and support functions or 
subfunctions as may be desirable to perform the operations 
required in certain business models, provide maximum efficiency, 
and/or maximize convenience. For example, Anne's Commerce 
Utility System 90(2) might provide only a specialized subset of 
financial clearinghouse function 

Figure 7A shows another illustration of how Commerce 
Utility Systems 90 can offer a wide variety of different 
combinations or subcombinations of administrative and support 
functions. In this Figure 7A diagram, each of the various 
administrative and support service functions is represented (for 
purposes of illustration) as a different kind of child's play block: 

• financial clearing functions 200 are shown as square 
blocks, 

• Usage clearing functions 300 are shown as half-circle 
blocks, 

• Rights and permissions clearing functions 400 are 
shown as rectangular blocks, 

• Certifying authority functions 500 are shown as 
triangular blocks, 

• Secure directory service functions 600 are shown as 
tunnel blocks, and 
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• Transaction authority functions 700 are shown as 
cylinders. 

Consumer and user appliances 1 00 are shown as standing- 
up rectangular columns in the diagram. Electronic network 1 50 is 
shown as a road which connects the various Commerce Utility 
Systems to one another and to consumer electronic appliances 
100. Electronic digital containers 152 may be carried along this 
electronic network or "information highway" 150 between 
different electronic installations. 

Figure 7A illustrates just some of the many possible 
administrative and support service combinations that might be 
used. For example: 

• In the upper left-hand corner, a Commerce Utility 
System 90A provides at least some financial clearing 
functions 200a, at least some rights and permissions 
clearing functions 400a, and at least some certifying 
functions 500a. This type of overall electronic 
Commerce Utility System 90A might, for example, 
be in the business of managing and granting rights on 
behalf of rights holders and in handling payments 
based on those rights. 

• ' The Commerce Utility System 90D just to the right of 

installation 90A comprises financial clearing services 
200d and transaction authority services 700a. It 
might be especially useful in, for example, auditing 
and/or managing an overall complex multi-step 
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transaction while also ensuring that appropriate 
parties to the transaction are paid. 

• In the lower center of the diagram there is a 
Commerce Utility System 90B including financial 

5 clearing functions 200f and usage clearing functions 

300c. This Commerce Utility System 90B could be 
especially useful, for example, for handling payment 
and other financial details relating to electronic usage 
transactions and also providing audit and report 
1 0 services based on the electronic usage. 

• The Commerce Utility System 90C shown in the 
bottom center of the drawing combines certifying 
authority services 500 with usage clearing services 
300f. It could be especially useful in issuing digital 

1 5 certificates and then tracking the usage of those 

certificates (for example, in order to evaluate risks, 
potential liability, insurance costs, etc.). 

The various examples shown in Figure 7A are for purposes 
of illustration. Other combinations are possible or likely 
20 depending on business objectives, convenience and other factors. 

Commerce Utility System Hierarchies 

Figure 8A shows that Commerce Utility Systems 90 or 
functions can be arranged in a hierarchy. For example, an overall 
financial (or other) clearinghouse 200(N) may oversee and/or have 
25 ultimate responsibility for the operations of numerous other 
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financial (or other) sub-clearinghouses 200( 1 ), 200(2) In the 

Figure 8A example, a consumer electronic appliance 100 might 
interact with a clearinghouse 200(1), which might in turn interact 
with another clearinghouse 200(2), etc. This administrative and 
5 support service "hierarchy" might be thought of as being similar in 
some ways to a chain of command in a large corporation or in the 
military — with some clearinghouses exercising and/or delegating 
power, control and/or supervision over other clearinghouses. 
Figure 8B shows another example of a administrative and 

1 0 support service hierarchy. In this example, a number of 

centralized overall clearinghouses and/or other Commerce Utility 
Systems 90 delegate some or all of their work responsibilities to 
other Commerce Utility Systems 90. In this particular example 
shown, organizations, such as companies, non-profit groups or the 

1 5 like may have their own Commerce Utility Systems 1 56. Certain 
electronic commerce or other activities (the entertainment 
industry, for example) might have their own vertically-specialized 
Commerce Utility Systems 158. Certain geographical, territorial 
or jurisdictional groups (e.g., all purchasers of particular products 

20 within the state of Wisconsin) may have their own 

territorial/jurisdictional specialized Commerce Utility Systems 
160. Commerce Utility Systems 156, 158, 160 lower in the 
hierarchy may, in turn, further delegate authorities or 
responsibilities to particular consumers, organizations or other 

25 entities. 

In one example arrangement, the Commerce Utility Systems 
90 to which authority has been delegated may perform 
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substantially all of the actual support work, but may keep the more 
over arching Commerce Utility Systems 90 informed through 
reporting or other means. In another arrangement, the over 
arching Commerce Utility Systems 90 have no involvement 
5 whatsoever with day to day activities of the Commerce Utility 
Systems to whom they have delegated work. In still another 
example arrangement, the more specialized Commerce Utility 
Systems do some of the work and the more overarching 
Commerce Utility Systems do other parts of the work. The 

1 0 particular division of work and authority used in a particular 
scenario may largely depend on factors such as efficiency, 
trustedness, resource availability, the kinds of transactions being 
managed, and a variety of other factors. Delegation of clearing 
authority may be partial (e.g., delegate usage aggregation but not 

1 5 financial or rights management responsibilities), and may be 
consistent with peer-to-peer processing (e.g., by placing some 
functions within consumers' electronic appliances while keeping 
some more important functions centralized). 

Multi-Function Commerce Utility Systems Can be Organized 
20 Hierarchically or Peer-to-Peer 

Figure 9 shows a still different, more complex Commerce 

Utility System environment including elements of both a 

hierarchical chain of command and a high degree of cooperation 

in the horizontal direction between different multi-function 

25 Commerce Utility Systems 90. In this example, there are five 

different levels of responsibility with a master or overarching 

Commerce Utility Systems 90(1) (for example, a financial 
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clearinghouse 200) on level 1 having the most authority and with 
additional Commerce Utility Systems on levels 2, 3, 4, and 5 have 
successively less power, authority, control, scope and/or 
responsibility. Figure 9 also shows that different Commerce 
5 Utility Systems on the same level may have different functions, 
scopes and/or areas of responsibility. For example: 

• a Commerce Utility System 90(2)( 1 ) may be a "type A" 
Commerce Utility System, 

• Commerce Utility System 90(2)(2) might be a "type B" 
10 Commerce Utility System, and 

• Commerce Utility System 90(2)(3) might be a "type C" 
Commerce Utility System. 

On the next level down, Commerce Utility Systems might 
be type A Commerce Utility System (such as, 90(3 )( 1 ) and 

1 5 90(3 )(2)), they might be type B Commerce Utility Systems (such 
as, 90(3)(4)), they might be type C Commerce Utility Systems 
(such as, 90(3)(5), 90(3X6)), or they might be hybrids - such as, 
Commerce Utility System 90(3)(3) which is a hybrid having type 
A and type B functions. 

20 Figure 9 also shows that additional clearinghouses on levels 

4 and 5 might have sub-types as well as types. In the context of a 
financial clearinghouse 200 for example, Type A might be 
responsible for consumer credit, Type B for electronic checks, and 
Type C for commercial credit. Another demarcation might be 

25 clearing for Visa (Type A), Mastercard (Type B) and American 
Express (Type C). A Type A/B clearinghouse would then be a 
clearing delegation that could handle both consumer credit and 
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electronic check clearing. A Type B Subtype I might be 
responsible for commercial electronic checks. A Type C 
Subtype I might be commercial credit card transactions, and 
Subtype III might be credit drafts. The rationale for multiple 
5 instances might be based on jurisdictional boundaries (e.g., 
France, Germany, New York, and Alabama), and/or contractual 
arrangements (e.g., delegation of responsibility for bad credit 
risks, small purchasers, very large transactions, etc.) The peer-to- 
peer dimension might reflect a need to coordinate an overall 

10 transaction (e.g., between a small purchaser's clearinghouse and a 
large commercial player's clearinghouse). 

A rights and permissions clearinghouse 400 might break out 
along content types (e.g., movies; scientific, technical and 
medical; and software). Subtype A might include first run movies, 

1 5 oldies, and art films; subtype B might handle journals and 
textbooks; and type C might be responsible for games, office, 
educational content. Peer-to-peer communications between 
clearinghouses could involve multimedia presentation permissions 
(e.g., a multimedia presentation might have permissions stored at 

20 one clearinghouse that uses a back channel to other clearinghouses 
to ensure that the latest permissions are distributed). 

Some Example Commerce Utility Systems 

As described above, Commerce Utility Systems 90 are 
generalized and programmable — and can therefore provide a mix 
25 of different support and administration functions to meet 
requirements of a given transaction. Thus, many or most 
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Commerce Utility Systems 90 as actually implemented may 
provide a range of different support and administrative functions 
that may make it difficult to categorize the implementation as 
being of one particular "kind" of Commerce Utility System as 
5 opposed to another. 

Nevertheless, certain types of idealized specialized 
Commerce Utility Systems 90 are particularly useful for a wide 
range of models, transactions and applications. It is helpful and 
convenient to describe some of the characteristics of these "pure" 
1 0 Commerce Utility Systems of different types - recognizing that 
actual implementations may mix functions or function subsets 
from several of these idealized models. The following are brief 
vignettes of some of the characteristics of such "pure" idealized 
Commerce Utility Systems. 

15 Financial Clearinghouse 200 

Figure 1 0 shows an example financial clearinghouse 200 in 
more detail. Financial clearinghouse 200 handles payments to 
ensure that those who provide value are fairly compensated. 
Financial clearinghouse 200 may securely coordinate with other 

20 Commerce Utility Systems 90 in performing this task. 

In this example, financial clearinghouse 200 may 
communicate with appliance protected processing environment 
1 54 over electronic network 1 50 in a secure manner using 
electronic containers 152 of the type described, for example, in the 

25 Ginter et al. patent specification in connection with Figures 5 A 
and 5B. Financial clearinghouse 200 may receive payment 
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information 202 from protected processing environment 1 54 in 
these secure containers 152, and interact electronically or 
otherwise with various banking, credit card or other financial 
institutions to ensure that appropriate payment is made. 
5 Financial clearinghouse 200 may, for example, interact with 

a consumer's bank 206a, a provider's bank 206b and a consumer's 
credit card company 206c. For example, financial clearinghouse 
200 can debit funds from the consumer's bank 206a and credit 
funds to the rights holder's bank 206b to pay for the consumers' 

1 0 watching of a movie, television program or other content. 
Additionally or alternately, financial clearinghouse 200 may 
interact with a consumer's credit card company 206c to request 
credit checks, obtain credit authorizations, payments and the like. 
Financial clearinghouse 200 may provide payment 

1 5 statement statements 204 to consumers 95 — for example, by 
transmitting the statements to appliance 100 in a secure electronic 
container 152b to preserve the confidentiality of the statement 
information. In this example, consumers 95 can view the 
statements 204 using their appliance 100 protected processing 

20 environment 1 54, and may also be able to print or save them for 
record-keeping purposes. 

In one example, the payment mechanism 1 1 8 provided by 
protected processing environment 1 54 might be an electronic 
wallet supplying electronic money for use in paying for electronic 

25 services or content. This electronic wallet may hold money in 
digital form. Consumers 95 can spend the digital money on 
whatever they wish. When the electronic wallet is empty, 
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consumers 95 can have the financial clearinghouse 200 replenish 
the wallet by authorizing the financial clearinghouse to debit the 
funds from the consumers' account in their bank 206a. Financial 
clearinghouse 200 may process electronic money payments, 
5 arrange for the electronic wallet to be refilled automatically (based 
on the consumers' pre-authorization, for example) when the 
consumers have spent all of its former contents, and provide the 
consumers with detailed reports and statements 204 about how 
they have spent their electronic money. 

10 Usage Clearinghouse 300 

Figure 1 1 shows an example usage clearinghouse 300. 
Usage clearinghouse 300 in this example receives usage 
information 302 from usage meter 1 16, analyzes the usage 
information and provides reports based on the analysis it performs. 

1 5 Usage clearinghouse 300 may securely coordinate with other 
Commerce Utility Systems 90 in accomplishing these tasks. 

For example, usage clearinghouse 300 may send the 
consumers 95 a detailed report 304a of all the movies, television 
programs and other material the consumers have watched over the 

20 last month. The communication between protected processing 
environment 154 and usage clearinghouse 300 may be in the form 
of secure containers 152. As described in the Ginter et al. patent 
disclosure, usage meter 1 16 can meter use on the basis of a 
number of different factors, and can range from being extremely 

25 detailed to being turned off altogether. The consumers, if they 
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desire, could view the detailed usage report 304a on their 
television set 102. 

Usage clearinghouse 300 can report to others about the 
consumers' viewing habits consistent with protecting the 
5 consumers' privacy. These reports can also be sent within secure 
containers 1 52. For example, usage clearinghouse 300 might 
provide a summary report 304b to advertisers 306 that does not 
reveal the consumers' identity but provides the advertisers with 
valuable information about the consumers' viewing habits. On the 

1 0 other hand, with the consumers' consent, usage clearinghouse 300 
could provide a more detailed report revealing the consumers' 
identity to advertisers 306 or to other specified people. In return, 
the consumers 95 could be given incentives, such as, for example, 
discounts, cash, free movies, or other compensation. 

1 5 Usage clearinghouse 300 can also issue reports 304c to 

rights holders 308 - such as the producer or director of the video 
program 102a the consumers 95 are watching. These reports 
allow the rights holders to verify who has watched their program 
material and other creations. This can be very useful in ensuring 

20 payment, or in sending the consumers other, similar program 
material they may be interested in. 

Usage clearinghouse 300 might also send reports 304d to a 
ratings company 3 1 0 for the purpose of automatically rating the 
popularity of certain program material. Usage clearinghouse 300 

25 might also send reports to other market researchers 3 1 2 for 
scientific, marketing or other research. 
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Rights and Permissions Clearinghouse 400 

Figure 12 shows an example rights and permissions 
clearinghouse 400. Rights and permissions clearinghouse 400 
stores and distributes electronic permissions 404 (shown as a 
5 traffic light in these drawings). Permissions 404 grant and 

withhold permissions, and also define consequences. Rights and 
permissions clearinghouse 400 may work with other Commerce 
Utility Systems 90 to accomplish its tasks. 

In this example, rights and permissions clearinghouse 400 

1 0 may act as a centralized "repository" or clearinghouse for rights 
associated with digital content. For example, broadcasters, 
authors, and other content creators and rights owners can register 
permissions with the rights and permissions clearinghouse 400 in 
the form of electronic "control sets." These permissions can 

1 5 specify what consumers can and can't do with digital properties, 
under what conditions the permissions can be exercised and the 
consequences of exercising the permissions. Rights and 
permissions clearinghouse 400 can respond to requests 402 from 
electronic appliance protected processing environment 1 54 by 

20 delivering permissions (control sets) 1 88 in response. 

For example, suppose that consumers 95 want to watch a 
concert or a fight on television set 102. They can operate their 
remote control unit 108 to request the right to watch a certain 
program. Protected processing environment 1 54 may 

25 automatically contact rights and permissions clearinghouse 400 

over electronic network 150 and send an electronic request 402. 

The rights and permissions clearinghouse 400 can "look up" the 
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request in its library or repository to see if it has received (and is 
authorized to provide) the necessary permission 404b from the 
program's rights holder 400. It may then send the requested 
permission 188 to protected processing environment 154. 
5 For example, permission 1 88 might allow the consumers to 

view the concert or fight only once and prohibit its copying with 
copy protection mechanism 120. Permission 1 88 may also (or in 
addition) specify the price for watching the program (for example, 
$5.95 to be deducted from the consumers' electronic wallet). 

1 0 Appliance 1 00 can ask the consumers 95 if they want to pay $5.95 
to watch the program. If they answer "yes" (indicated, for 
example, by operating remote control 1 08), the appliance 1 00 can 
automatically debit the consumers' electronic wallet and "release" 
the program so the consumers can watch it. 

1 5 Rights and permissions clearinghouse 400 can deliver 

permissions 188 within a secure container 152b that may 
optionally also contain the information controlled by the 
permissions — or permission 188 may arrive at a different time and 
over a different path than the program or other content travels to 

20 the appliance 100. For example, the permissions could be sent 
over network 1 50, whereas the program it is associated with may 
arrive directly from satellite 1 12 or over some other path such as 
cable television network 1 14 (see Figure 1 ). 

Rights and permissions clearinghouse 400 may also issue 

25 reports 406 to rights holders or other people indicating which 

permissions have been granted or denied. For example, the author 
of a book or video might, consistent with consumer privacy 
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concerns, be able to learn the exact number of people who have 
requested the right to publish excerpts from his or her work. 
These kinds of reports can supplement reports provided by usage 
clearinghouse 300. 

5 Certifying Authority 500 

Figure 13 shows an example of a certifying authority 500. 
Certifying authority 500 issues digital certificates 504 that provide 
a context for electronic rights management. Certifying authority 
500 may coordinate with other Commerce Utility Systems 90 to 

1 0 accomplish its tasks. 

Certifying authority 500 issues digital certificates 504 that 
certify particular facts. Digital certificate 122 is like a driver's 
license or a high school diploma in some respects, since they each 
provide proof of a certain fact For example, we may show our 

1 5 drivers' license to prove that we are old enough to vote, buy 
liquor, or watch an "R" rated movie. This same driver's license 
attests to the fact that we have a certain name and live at a certain 
address, and that we have certain knowledge (of state motor 
vehicle laws) and skills (the ability to maneuver a motor vehicle). 

20 Digital certificate 504 is similar to that aspect of a driver's license 
that confirms the identity of, and related facts pertaining to the 
licensee, except that it is made out of digital information instead of 
a laminated card. 

In this example, certifying authority 500 may receive 

25 consumer requests and associated evidence 502, and may issue 
corresponding digital certificates 504 that certify particular facts. 
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Certifying authority 500 may also receive evidence, credentials 
and possibly also certificate definitions from other people such as 
government authorities 506, professional organizations 508 and 
universities 510. As one example, the certifying authority 500 
5 might receive birth certificate or other identity information from a 
government authority 506. Based on this identity information, the 
certifying authority 500 may prepare and issue a digital certificate 
504 that attests to person's identity and age. The certifying 
authority 500 might also issue digital certificates 504 attesting to 

1 0 professional status, employment, country of residence, or a variety 
of other classes and categories based on various evidence and 
inputs from various people. 

Certifying authority 500 may certify organizations and 
machines as well as people. For example, certifying authority 500 

1 5 could issue a certificate attesting to the fact that Stanford 

University is an accredited institution of higher learning , or that 
the ACME Transportation Company is a corporation in good 
standing and is authorized to transport hazardous materials. 
Certifying authority 500 could also, for example, issue a 

20 certificate 504 to a computer attesting to the fact that the computer 
has a certain level of security or is authorized to handle messages 
on behalf of a certain person or organization. 

Certifying authority 500 may communicate with protected 
processing environment 1 54 and with other parties by exchanging 

25 electronic containers 152. Electronic appliance 1 00' s protected 
processing environment 154 may use the digital certificates 504 
the certifying authority 500 issues to manage or exercise 
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permissions 1 88 such as those issued by rights and permissions 
clearinghouse 400. For example, set top box 1 06 might 
automatically prevent any consumer under 17 years of age from 
watching certain kinds of program material, or it might provide a 
5 payment discount to students watching educational material ~ all 
based on certificates 504 issued by certifying authority 500. 

Secure Directory Services 

Figure 14 shows an example of secure directory services 
600. Secure directory services 600 acts something like a 

1 0 computerized telephone or name services directory. Consumers 
95 can send a request 602 specifying the information they need. 
Secure directory services 600 can "look up" the information and 
provide the answer 604 to consumers 95. Secure directory 
services 600 can work with other Commerce Utility Systems 90 to 

1 5 perform its tasks. 

For example, suppose consumers 95 want to electronically 
order a pizza from Joe's Pizza. They decide what kind of pizza 
they want (large cheese pizza with sausage and onions for 
example). However, they don't know Joe's Pizza's electronic 

20 address (which may be like an electronic phone number). 

Consumers 95 can use remote control 1 08 to input information 
about what they want to have looked up ("Joe's Pizza, Lakeville, 
Connecticut"). Protected processing environment 154 may 
generate a request 602 containing the identification information 

25 and send this request to secure directory services 600. It can send 
the request in a secure container 152a. 
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When secure directory services 600 receives the request 
602, it may access a database to locate the requested information. 
Secure directory services 600 may have earlier obtained Joe's 
electronic address directly from Joe or otherwise. Secure 
5 directory services 600 may send the requested information back to 
appliance 100 in a response 604. Response 604 may also be in a 
secure container 152b. The consumers 95 can use this information 
to electronically send their order to Joe's Pizza - which can 
display on Joe's order terminal within a few seconds after the 

1 0 consumers send it. Joe may deliver to consumer 95 a piping hot 
cheese, sausage and onion pizza a few minutes later (by car - not 
electronically - since a physical pizza is much more satisfying 
than an electronic one). 

Secure directory services 600 can help anyone connected to 

1 5 network 1 50 contact anyone else. As one example, secure 
directory services 600 can tell usage clearinghouse 300 how to 
find a financial clearinghouse 200 on network 150. Any electronic 
appliance 100 connected to network 150 could use secure 
directory services 150 to help contact any other electronic 

20 appliance. 

As mentioned above, the request 602 to secure directory 
services 600 and the response 604 it sends back may be encased 
within secure containers 152 of the type described in the Ginter et 
al patent specification. The use of secure containers 152 helps 

25 prevent eavesdroppers from listening into the exchange between 
consumers 95 and secure directory services 600. This protects the 
consumers' privacy. The consumers 95 may not care if someone 
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listens in to their pizza order, but may be much more concerned 
about protecting the fact that they are corresponding electronically 
with certain other people (e.g., doctors, banks, lawyers, or others 
they have a relationship of confidence and trust with). Secure 
5 containers 152 also help ensure that messages sent across network 
1 50 are authentic and have not been altered. Electronic containers 
152 allow Joe's Pizza to trust that the just-received pizza order 
actually came from consumers 95 (as opposed to someone else) 
and has not been altered, and the consumers can be relatively sure 
1 0 that no one will send Joe a fake pizza order in their name. The use 
of secure containers 152 and protected processing environment 
154 in the preferred embodiment also ensures that the consumers 
95 cannot subsequently deny that they actually placed the order 
with Joe's Pizza if they in fact did so. 
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Transaction Authority 700 

Figure 1 5 shows an example transaction authority 700. 
Transaction authority 700 in this example provides process control 
and automation. It helps ensure that processes and transactions 
5 are completed successfully. Transaction authority 700 may work 
with other Commerce Utility Systems 90 to perform and complete 
its tasks. 

In more detail, transaction authority 700 in this example 
monitors the status of an electronic transaction and/or process and 

1 0 maintains a secure, reliable record of what has happened so far and 
what still needs to happen for the overall transaction and/or 
process to complete. Transaction authority 700 may also, if 
desired, perform a more active role by, for example, generating 
requests for particular actions to occur. Transaction authority 700 

1 5 may in some cases be the only participant in a complex transaction 
or process that "knows" all of the steps in the process. 
Transaction authority 700 can also electronically define an overall 
process based on electronic controls contributed by various 
participants in the process. 

20 Figure 1 5 illustrates an example of how transaction 

authority 700 can be used to allow consumers 95 to order 
merchandise such as a sweater. In this particular electronic home 
shopping example (which is for purposes of illustration but is not 
intended to be limiting in any way), the consumers 95 can use 

25 their remote control 1 08 to select the particular seller, style and 

color of a sweater they want to order at a particular price. In this 

home shopping example, appliance 100's protected processing 
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environment 154 may generate an electronic order 702 which it 
sends to the order receiving department 704 of an electronic "mail 
order" company. The order 702 may be sent within a secure 
container 152a. 

In this example, transaction authority 700 may assist the 
electronic mail order company to coordinate activities and make 
sure that all steps required to deliver the sweater are performed in 
an accurate and timely fashion. For example: 

• Upon receiving the electronic order 702, the order 
receiving department 704 might provide an electronic 
notification 706 to transaction authority 700. The 
transaction authority 700 stores the electronic 
notification 706, and may issue a "requirement" 708. 

• Transaction authority 700 may have issued the 
requirement 708 before the order was placed so that 
the order receiving department 704 knows what to do 
when the order comes in. 

• In accordance with the "requirement" 708, order 
receiving department 704 may issue an electronic 
and/or paper (or other) version of the order 7 1 0 to a 
manufacturing department 712. 

•. The transaction authority 700 may issue a 

manufacturing requirement 714 to the manufacturing 
department to make the sweater according to the 
consumers' preferences. 
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• Transaction authority 700 might also issue a supply 
requirement 7 1 6 to a supplier 718. For example, 
transaction authority 700 may request supplier 71 8 to 
deliver supplies, such as balls of yarn 71 1, so 
manufacturer 712 has the raw materials to 
manufacture the sweater. 

• Supplier 7 1 8 may notify transaction authority 700 
when it has delivered the supplies by issuing a 
notification 720. 

• When manufacturing department 7 1 2 has finished the 
sweater, it may alert transaction authority 700 by 
sending it a notification 722. 

• In response to the notification 722 sent by 
manufacturing department 712, transaction authority 
700 may issue a shipping requirement 724 to a 
shipping department 726, for example, requesting the 
shipping department to pick up completed sweater 
728 from the manufacturing department and to 
deliver it to the consumers. 

• Transaction authority 700 may coordinate with other 
Commerce Utility Systems 90, such as a financial 
clearinghouse 200, to arrange payment. 

Of course, this example is for purposes of illustration only. 

Transaction authority 700 may be used for all kinds of different 

process control and automation such as, for example, handling 

electronic orders and sales, electronic data interchange (EDI), 
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electronic contract negotiation and/or execution, electronic 
document delivery, inter and intra company transactions, and the 
secure electronic integration of business processes within or 
among business organizations - just to name a few of many useful 
5 applications. 

VDE Administration Services 800 

VDE administrator 800 (see Figure 1 of this application and 
Figures 1 A and associated discussion in the Ginter et al. 
specification) may, in the preferred embodiment, provide a variety 

10 of electronic maintenance and other functions to keep network 
1 50, appliance 1 00 protected processing environments 1 54 and 
Distributed Commerce Utility 75 operating securely, smoothly and 
efficiently. For example, VDE administrator 800 may manage 
cryptographic keys used for electronic security throughout 

1 5 network 1 50, and may also provide services relating to the 
maintenance of secure data by appliances 100, the various 
Commerce Utility Systems 90, and other electronic appliances. 
As described in detail in the Ginter et al. patent disclosure, other 
important functions performed by VDE administrator 800 include 
20 installing and configuring protected processing environments 1 54, 
and helping protected processing environments to securely 
maintain stored permissions and/or usage data. The VDE 
administrator 800 may work with other Commerce Utility Systems 
90. 
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Commerce Utility Systems 90 Can Support One Another 

In addition to supporting consumers 95, Commerce Utility 
Systems 90 can support other Commerce Utility Systems. This is 
shown in Figures 16A - 16F. For example: 
5 • financial clearinghouse 200 can help ensure other 

Commerce Utility Systems 90 are paid for their 
contributions (see Figure 16A); and 

• usage clearinghouse 300 (see Figure 1 6B) may 
inform other Commerce Utility Systems 90 

1 0 concerning how the support they provide is being 

used. For example, usage clearinghouse 300 may tell 
certifying authority 500 how the certifying authority's 
certificates have been used (very useful for the 
certifying authority to keep tabs on the amount of 

1 5 potential liability it is undertaking or in helping to 

detect fraudulent certificates). 

• Figure 16C shows that a rights and permissions 
clearinghouse 400 can support other Commerce 
Utility Systems 90 such as, for example, a financial 

20 clearinghouse 200, a usage clearinghouse 300, 

another rights and permissions clearinghouse 400', a 
certifying authority 500, a secure directory services 
600, and a transaction authority 700. 

• Certifying authority 500 can issue digital certificates 
25 504 certifying the operation of one or more other 

Commerce Utility Systems 90 (see Figure 1 6D) - 

80 



supporting other Commerce Utility Systems 90 such 
as, for example, a financial clearinghouse 200, a 
usage clearinghouse 300, a rights and permissions 
clearinghouse 400, another certifying authority 500', 
secure directory services 600, and transaction 
authority 700. 

• Figure 16E shows that a secure directory services 600 
may support other Commerce Utility Systems 90, 
such as, for example, financial clearinghouse 200, 
usage clearinghouse 300, rights and permissions 
clearinghouse 400, certifying authority 500, other 
secure directory services 600', and transaction 
authority 700. 

• Figure 16F shows that a transaction authority 700 can 
support other Commerce Utility Systems 90, such as, 
for example, a financial clearinghouse 200, a usage 
clearinghouse 300, a rights and permissions 
clearinghouse 400, a certifying authority 500, a 
secure directory services 600, and another transaction 
authority 700'. 

"A Piece of the Tick" 

The Commerce Utility Systems 90 described herein provide 
valuable, important services and functions. The operators of such 
services can and should be compensated for the services they 
provide. Financial Clearinghouse Commerce Utility Systems 200 
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can ensure that they and other support service providers receive 
this compensation without inconvenience to other electronic 
community and value chain participants. 

In assisting or compensating value chain participants, a 

5 Commerce Utility System 90 may (based on pre-approved 
contractual arrangements) take its own portion or percentage to 
compensate it for the clearing services it provides. Support 
services can be compensated based on a small portion of payment 
(i.e., a "micro-payment") attributable to each electronic 

1 0 transaction (a "piece of the tick"). Providers may pass some or all 
of these fees along to their own value chain participants in various 
ways. 

Several different classes of value chain participants may be 
called upon to compensate the Commerce Utility Systems 90, 
1 5 including: 

• Information Consumers (including for example, 
people who make use of the information "exhaust" 
generated by electronic commerce, electronic 
transaction management and rights management 

20 activities); 

• Content Rightsholders and other Electronic 
Providers; 

• Participants in the broadest range of secure, 
distributed electronic commerce transactions.; 
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• In addition, various support service providers may 
also need to support one another in various ways - 
and may therefore need to compensate one another. 
For example: 

5 • One Commerce Utility System 90 may act as an 

intermediary for another Commerce Utility System 
90's customer, 

• One Commerce Utility System 90 may be required to 
support the operation of another Commerce Utility 

10 System 90; and/or - ' 

• Commerce Utility System 90s may need to work 
together to support a common transaction. 

Different Commerce Utility System 90s may cooperate to 
establish a common fee that they then divide among themselves. 
1 5 In another scenario, each Commerce Utility System 90 may 

independently charge for the value of its own services. There may 
be competition among different Commerce Utility System 90s 
based on quality of service and price - just as credit card 
companies now compete for providers' and consumers' business. 

Example Distributed Commerce Utility System Architecture 

The Ginter et al. patent disclosure describes, at pages 180 
and following, and shows in Figure 10-12, for example, a "Rights 
Operating System" providing a compact, secure, event-driven, 
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compartmentalized, services-based, "component" oriented, 
distributed multi-processing operating system environment that 
integrates VDE security control information, components, and 
protocols with traditional operating system concepts. The 
5 preferred example Commerce Utility System 90 architecture 
provided in accordance with these inventions builds upon and 
extends the Rights Operating System described in Ginter et al. 

For example, the preferred example Commerce Utility 
System 90 architecture provides a collection of service functions 

1 0 that the Rights Operating System may execute as applications. 
These service functions define a variety of useful tasks that any 
and/or all Commerce Utility Systems 90 may need to perform. 
These service functions are distributable, scaleable and reusable. 
They can be combined in various combinations and sub- 

15 combinations — depending upon business models, for example — 
to provide the overall functionality desired for any particular 
Commerce Utility System 90 implementation. 

Figure 17A shows an example overall architecture of a 
Commerce Utility System 90, Figure 17B shows an example of 

20 the application architecture of a Commerce Utility System, and 
Figure 1 7C shows more detail of a service function. 

Referring first to Figure 17B, in this example the 
application software architecture for a Commerce Utility System 
90 contains a commerce utility system descriptor 90A. Commerce 

25 utility system descriptor 90A contains information about the 
Commerce Utility System 90 that may be used to identify such 
system and its capabilities, as well as to describe, aggregate and/or 
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interface with any number of service functions 90B( 1 ), 90B(2) 

Commerce utility system descriptor 90A and service functions 
90B may, for example, be implemented using object oriented 
programming techniques to help ensure that such descriptor and 
5 service functions are modular and reusable ~ as well as 

abstracting the specifics of how actions requested of Commerce 
Utility System 90 are actually carried out and/or implemented. 

Commerce utility system descriptor 90A(1) may also be 
responsible for coordinating the action of service functions 90B. 

1 0 In this example, descriptor 90A is used to direct requests and other ; 
system actions to the appropriate service functions 90B, and to 
ensure that actions requiring more than one service function are i 
coordinated by reconciling differences in interfaces, data types 
and the like that may exist between the service functions 90B — as ; 

1 5 well as helping to direct overall process flow amongst the various s 
service functions 90B. A non-exhaustive list of examples of such r 
service functions 90B include the following: 

• audit, 

• maintaining records, 
20 • overseeing processes, 

• monitoring status, 

• complete process definition, 
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process control, 

interface(s) to settlement services, 

funds transfer, 

currency conversion, 

tax calculation and application, 

account creation and identifier assignment, 

payment aggregation, 

payment disaggregation, 

budget pre-authorization, 

status notification, 

confirmation, 

uncompleted events record, 
requirements generation, 
report generation, 
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• event consequences, 

• account reconciliation, 

• identity authentication, 

• electronic currency creation, 
5 • event database management, 

• routing database, 



• generating requests, 

• replication, 

• propagation, 

10 • usage database management, 

• bill creation and processing, 

• market research, 



• negotiation, 

• control set database management, 
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• control set generation, 

• process control logic, 

• event flow generation, 

• routing, 

5 • archiving, 

• rights and permissions database management, 

• template database management, 

• commerce management language processing, 

• rights management language processing, 
10 • advertising database management, 

• automatic class generation, 

• automatic class assignment, 

• notary, 

• seal generator, 
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• digital time stamp, 



• fingerprint/watermark, 

• offers and counteroffers, 

• object registry, 

5 • object identifier assignment, 

• copyright registration, 

• control set registry, 

• template registry, 

• certificate creation, 

10 • revocation list maintenance, 

• director database management, 

• database query and response processing, 
• other service functions. 

Figure 1 7C shows more detail of a service function 90B. In 
1 5 this example, service function 90B is comprised of a service 
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function descriptor 90C, and any number of service application 
components 90D(1), 90D(2), .... Service function descriptor 90C 
performs a role similar to that of commerce utility system 
descriptor 90A, except that it acts with respect to service function 
5 90B and service application components 90D. Service function 
descriptor 90C and service application components 90D may, for 
example, also be implemented using object oriented programming 
techniques to help ensure that such descriptor and service 
application components are modular and reusable, as well as 

1 0 abstracting the specifics of how actions requested of service 

function 90B are actually carried out and/or implemented. In this 
example, the service application components 90D implement most 
of the capabilities of the service function 90B by carrying out 
steps of, or subfunctions of, the service function 90B. 

1 5 Figure 17A shows an example overall Commerce Utility 

System 90 architecture. The overall architecture shown in this 
example is an object oriented system in which the overall 
Commerce Utility System 90 is a single object, that is in turn 
comprised of reusable service function 90B objects. These service 

20 function 90B objects are comprised of reusable service application 
components (objects) 90D. Any or all of these objects may make 
use of the services provided by a commerce utility support service 
layer 90-4, as described in more detail below. The preferred 
embodiment Commerce Utility System architecture 90 shown is 

25 built upon the Rights Operating System 90-1 described in detail in 
the Ginter et al. patent specification (see Figure 12 of Ginter, et al., 
for example). A set of service functions 90B comprise 
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"applications" executed by the Rights Operating System 90-1 . 
There can be any number of service functions 90B. 

The object oriented design of the Commerce Utility System 
90 architecture shown in Figure 1 7A has several desirable 
5 attributes. For example, a Commerce Utility System 90 may 
easily add, remove and/or replace service functions 90B to alter, 
extend and/or enhance its capabilities. Similarly, the architecture 
allows the addition, removal, and/or replacement of service 
application components 90D to permit similar flexibility in the 

10 case of service functions. Furthermore, object oriented design 
significantly improves the ease and efficiency of reuse of service 
functions and/or service application components in different 
Commerce Utility Systems 90, or different service functions 90B 
(as shown in Figure 1 7A); respectively. 

1 5 The application layer, which is comprised of service 

function layer 90-2 and service application component layer 90-3 
(comprising components 90D A ), may be, if desired, supported by a 
commerce utility support services layer 90-4. Commerce utility 
support services layer 90-4 may provide increased efficiency for 

20 large numbers of transactions. Such commerce utility support 
services 90-4 may include, for example: 

• session management, 

• fault tolerance, 

• memory management, 
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• database bridging, and 

• other commerce utility support services. 

In this example, service functions 90B are component 
5 based, and may make use of the reusable and component based 
service application components 90D. The service application 
components 90D typically perform steps of, or subfunctions of, 
service functions 90B. Each service application component 90D 
can have either or both of two parts: 
1 0 a component 90-B a that need not execute within protected 

processing environment 154; and 

a secure component 90-B b that needs to execute within 
protected processing environment 154. 

1 5 In this example architecture, there may be a correspondence 

between components 90D a and components 90D h . For example, at 
least one component 90D, may correspond with at least one 
secure component 90D b . There may be a one-to-one 
correspondence between components 90-D a and components 

20 90D b (as indicated in Figure 17A by common geometric shapes). 
In the preferred embodiment, this separation of function permits, 
when required and/or desired, the interaction between secure 
processes operating in PPE 154 and service application 
components 90D. By using this architecture, it is easier and more 
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efficient to create service functions that implement capabilities 
requiring both application level support as well as secure 
processing. 

For example, some administrative and/or support functions 
5 for performance by commerce utility systems 90 may involve use 
of both application level database functions as well as information 
protected by a protected processing environment ("PPE") 154 in 
the preferred embodiment. A specific example of this might be 
the records of payment by a user of a financial clearinghouse 200. 

1 0 If the operator of such a financial clearinghouse 200 chose to 

keep payment history information in an application level database, 
but needed information protected by PPE 154 in order to 
accurately determine the current account status of a customer, 
implementing a service application component 90D A that 

1 5 coordinated the information in the application level database with 
information protected by PPE 1 54 and processed by service 
application component 90D B into a single object may significantly 
simplify the task of using this information in the context of a 
given service function 90B (e.g. a decision to extend additional 

20 credit). Furthermore, this example service application component 
may be reusable in other service functions 90B. 

In another example, service application component 90D A 
might serve principally as an application level interface object to a 
corresponding PPE 1 54 object 90D B . For example, if a notary 

25 service function 90B requires the application of a digital signature, 
a service application component 90D A might principally provide 
an interface that transports information to, and receives 
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information from, a corresponding service application component 
90Db that performs essentially all of the actual work of creating 
and applying a digital signature. In addition, the application level 
service component 90D A might provide additional exception 
5 handling, protocol conversion, or other functions designed to help 
integrate capabilities more easily or in a different manner than 
originally designed for a service function 90B. 

Figure 17D-1 shows an example correspondence between 
service functions 90B and general types of useful example 

10 commerce utility systems 90. Example service functions 90B 
("Audit", "Maintaining Records", ...) are shown horizontally. 
These example service functions 90B may be useful for 
implementing commerce utility system 90 example types 
("Financial Clearinghouse", "Usage Clearinghouse", ...) written 

15 vertically in the row of boxes along the top of the diagram. The 
Figure 17D-1 diagram is not exhaustive - additional useful 
commerce utility system types are possible and additional service 
functions 90B are also possible. Indeed, the architecture of 
Commerce Utility System 90 ensures that both types and service 

20 functions 90B are extensible as business models or other factors 
change. 

Although certain business needs and models may tend to 
inspire trie use of certain combinations and collections of 
important service functions in almost any implementation, the 
25 Commerce Utility System 90 architecture is inherently flexible - 
allowing the implementer to freely mix and combine a variety of 
different service functions depending upon their needs. For 
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example, it is useful to provide a Commerce Utility System 90 that 
functions as a "financial clearinghouse 200" - providing payment 
processing, communications, database management, and other 
related service functions. The Commerce Utility System 
5 architecture can provide such a "financial clearinghouse" - and is 
also inherently much more generalized and general izable. For 
example, a particular Commerce Utility System 90 
implementation of a "financial clearinghouse" could also combine 
"non-financial" service functions with financial service functions. 

1 0 The particular functions or sets of functions that are realized in 
any given Commerce Utility System 90 implementation depend 
upon the individual needs of the implementer - as dictated for 
example by business model(s) or functions. 

Figure 17D-2 shows, for example, how the overall 

1 5 functionality of an example "financial clearinghouse" commerce 
utility system 200 can be constructed from example service 
functions 90B. In this example, the service functions 90B 
surrounded by darker lines are included within the commerce 
utility system descriptor 90a shown in Figure 17B. Figure 17D-2 

20 shows an example usage clearinghouse commerce utility system 
300 constructed based on a different subset of service functions 
90B surrounded by dark lines (shown in Figure 17D-1). 
Comparing Figures 17D-2 and 17D-3, one can see that some 
service functions 90B (for example, "audit," "status notification," 

25 "event database management,'* etc.) may be reused for both 

financial and usage clearing operations. A combination financial 
and usage clearinghouse commerce utility system 90 might use the 

95 



WU5WHU8I PCT7US96/14262 

union of the service functions 90B surrounded by dark lines in 
Figure 17D-2 and the service functions 90B surrounded by dark 
lines in Figure 17D-3. More, less and/or different functionality 
can be provided for a particular commerce utility system 90 
5 simply by providing and invoking more, less and/or different 
service functions 90B. 

Distributing Commerce Utility System 90 

The secure application components 90-3 described above 
may, in the preferred embodiment, include or comprise reciprocal 

10 control structures and associated rules and methods shown in 
Figures 41 A-4 ID and 48 of the Ginter et al. patent application. 
These reciprocal control structures can be used to interlink 
different or the same control sets operating on the same or 
different Commerce Utility Systems 90 or other electronic 

1 5 appliances 100. Hence, each actor can have one or more 

reciprocal relationships with every other actor ~ with Commerce 
Utility System 90 involved in some role in some of the various 
actions. 

Figures 17E-1 through 17E-4 show different examples of 
20 interaction models Commerce Utility System 90 may use to 
interact with an ongoing transaction or process based in part on 
these reciprocal control structures: 

• Figure 1 7E-1 shows an event intermediation model in 
which a Commerce Utility System 90 receives an event 
25 notification 748 from a secure entity (e.g., a first 

protected processing environment) and generates an 
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event 758 which triggers activities of another (and/or the 
same) secure entity (e.g., a second and/or the first 
protected processing environment). 

• Figure 1 7E-2 shows a different Commerce Utility 

5 System interaction model in which the first secure entity 

provides event notification 748 to both a Commerce 
Utility System 90 and another secure entity to perform a 
step, but the second entity awaits receipt of an 
authorization from Commerce Utility System 90 to 
1 0 proceed before it actually performs the next step in the 

process. 

• Figure 17E-3 shows a notification model in which 
Commerce Utility System 90 is more of a passive 
bystander, receiving event notifications 748 for purposes 

1 5 of secure auditing but otherwise not interacting directly 

with the ongoing process or transaction unless needed to 
resolve exceptions (e.g., an error condition). 

• Figure 17E-4 shows a prior authorization model in which 
the Commerce Utility System 90 must issue a 

20 notification 748' to one secure entity in response to 

receipt of an event notification 748 from that entity 
before that entity may pass the event notification 748 
along to the next secure entity to perform the next step in 
a overall process or transaction. 
25 The various Commerce Utility System 90 interaction 

models shown in Figures 17E-1 through 17E-4 are not exhaustive 
or mutually exclusive — any given transaction or process may 
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include some or all of these in different combinations based upon 
business models or other requirements. 

As mentioned above, the present inventions provide 
techniques for distributing the operation of a particular service 
function 90-2 or service application component 90-3 throughout a 
system 50 or network - including for example to electronic 
appliances of individual consumers 95. Figure 17F shows an 
example of a control set 188 that can be used to control a remotely 
located protected processing environment (for example, a 
consumer's electronic appliance) to perform a "local" portion of a 
clearing operation. A Commerce Utility System 90 could deliver 
this control set 188 to a consumer's electronic appliance, to 
another Commerce Utility System 90, or to some other electronic 
appliance (e.g., one that is part of a communicating infrastructure). 
The Commerce Utility System 90 can, for example, delegate part 
of its clearing authority (implemented, for example, as one or 
more service functions 90-2, each including one or more service 
application components 90-3) to a process that can be performed 
within the protected processing environment 1 54 of a user's 
electronic appliance. 

The Figure 17F example is a method 850 (e.g., meter, 
billing, or budget) whose AUDIT event 852(1) is processed by an 
audit method 854. The example meter method 850, for example, 
might have: 

• a USE event 852(2) (e.g., "click" the meter), 

• an INITIALIZE event 852(1) (e.g., prepare the meter for 

use), 
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• a RESET event 852(3) (e.g., restore the meter to a known 
good state after an error condition), 

• an AUDIT event 852(4) (e.g., gather up records generated 
during USE events, as well as a copy of the current 
UDE value, and arrange for shipment to the 
auditors)), 

• a READ USE RECORD event 852(5) (e.g., return a copy 
of the requested use record), 

• a READ UDE event 852(6) (e.g., return a copy of the 
current UDE), 

• a READ MDE event 852(7) (e.g. that returns a copy of the 
requested MDE), and 

• other miscellaneous events. 

15 The AUDIT event 852(4), in this example, may be linked to 

an audit method 854. In order to access the data in this example, 
the Commerce Utility System 90 might need permission in the 
form of access tags and/or an appropriate PERC control set 
defining more detailed usage permissions, and semantic 

20 knowledge of the record format written out by the meter method 
850's USE event 852(2). The semantic knowledge could come 
from an out-of-band agreement (e.g., a standard), or through 
access to the MDE (or relevant MDE portion) of the meter method 
850 that describes the use record format. 

25 The events of audit method 854 would include a USE event 

856(2) that performs the functions expected by the calling 
method's event — in this case, gathering use records and a copy of 
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the current UDE, and sending them off. In this example, let's 
assume there is an INITIALIZE event 856(1) in this method as 
well. When called, the INITIALIZE event 856(1 ) would be sent 
internally, and its associated load module(s) would call back to the 
READ MDE event 852(7) of the meter method 850 to learn the 
semantics of the use records. Then, the USE event 856(2) would 
be called and the load module(s) 858(2) associated with 
processing this event would call the appropriate events of the 
meter method 850 (e.g., READ USE RECORD repeatedly, and 
READ UDE once). At this point, the expectations of the calling 
method have been fulfilled, except for administrative object 
packaging and transmission. 

In order to implement more distributed clearing functions, 
the USE event 856(2) may do more processing. For example, 
while reading in the USE records from the meter, the audit method 
854 may implement analysis functions (e.g., categorizing the types 
of objects used, and reducing the information reported up the 
clearing chain to a simple count of how many times various types 
of content were accessed). Records from content types that are not 
interesting may be discarded. The detailed records themselves 
may be discarded after analysis. In another example, the UDE 
values (e.g., how many clicks are recorded) may be compared to 
the number of use records retrieved, and if there is a discrepancy, 
they can be reported and/or acted upon locally (e.g., disabling use 
of the objects from a given provider until further interaction). In 
still another example, records may have user identity information 
removed to ensure privacy. In a further example, some use 
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records may be processed and analyzed locally (and then 
discarded), while other detail records are saved for later 
processing. 

Once the distributed clearing functions have been 
5 performed, the information can be packaged up in one or more 
administrative objects for transmission up the clearing chain to a 
centralized location. This may involve a direct report to the 
providers), and/or a report to another clearing function, for 
example. The processed records may be released (for deletion, 

1 0 summary, filing, etc. by the meter method) by the audit method 
854 when received, processed, transmitted, or on receipt of a 
confirmation by the recipients. 

In another example using the meter method 850 shown in 
Figure 17F, the AUDIT event 854 could be performed "internally" 

15 by the meter method 850. In this example, the use records and 
UDE would be bundled up in one or more administrative objects 
for transmission to the auditors) by the load module(s) 853 
associated with the AUDIT event 854(4) of the meter method 850. 
However, rather than transmitting these objects, they could be 

20 processed locally. To do this, the name services record used by 
ROS (see Ginter et al. Figures 12 and 13) to find the named 
auditors) could be redirected back to the local PPE 154. In the 
PPE 1 54, a process controlled by the Commerce Utility System 90 
can be created (based on methods and/or load modules delivered 

25 on their behalf) to perform the local clearing functions described 
above, except using the content of the administrative object(s), 
rather than calls to the meter method events. This is more 
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analogous to the function that would be performed at a remote 
clearing facility in the sense that the operations are performed on 
administrative objects and their contents - but the processing can 
instead be done on the local consumer electronic appliance, on a 
5 networked appliance. 

Distributing support services in this manner provides 
additional capabilities that may not be present or available in a 
centralized architecture. For example, a rights and permissions 
clearinghouse could delegate a local server within an organization 

10 to keep track of requests and to cache copies of permissions 

previously requested by the organization. Such a local rights and 
permissions clearinghouse could reduce network traffic and 
provide a convenient local repository for organization-specific 
permissions (e.g., site licenses for computer software). The local 

1 5 rights and permissions server could be authorized by rights 
holders or a rights and permissioning agency or other rights 
distribution organization to grant licenses on a request basis. 

As another example, many secure, largely automated 
administrative and support services may be distributed in whole 

20 and/or in part to an at least occasionally connected appliance ~ 
regardless of whether that appliance is a computer, set top box, 
personal digital assistant (PDA) digital telephone, intelligent 
digital television, or any other digital appliance. Such appliances 
can use a protected processing environment to ensure that the 

25 support service is performed securely and reliably, free from 
tampering and other interference (e.g., as described in the Ginter, 
et al. patent specification). 
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In another example, one possible VDE content distribution 
scenario involves content providers performing the initial 
packaging role, distributors performing the distribution function, 
users keeping track of usage records, and clearinghouses 
5 processing usage and financial information. This is in contrast to 
a centralized processing model, in which all of these functions are 
performed by a single centralized party. 

As still another example, efficiency increases can be 
realized by distributing clearinghouse functions across individual 
1 0 user machines, local area network (LAN) servers, and/or corporate 
"gateway" machines that bridge the corporate LAN/WAN 
environment with the outside world, and commercial "backbone" - 
servers. 

As another example, a company's computer might be 
1 5 authorized by a central certificate authority to grant certain kinds 
of digital certificates. For example, the company might be a 
member of a certain trade organization. The trade organization's 
certifying authority might give the company a digital certificate 
attesting to that fact, and delegate to the company's own computer 
20 the certifying authority to issue certificates attesting to the fact 
that each of the company's employees is a member of the trade 
organization. Similarly, parents may be authorized to issue digital 
certificates on behalf of their offspring. 

The techniques described above illustrate how the 
25 Distributed Commerce Utility, through use of the Commerce 
Utility System 90 architecture, can be distributed across multiple 
Commerce Utility Systems. Furthermore, the service functions 
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90-2 provided by one or more Commerce Utility Systems 90 may 
be decomposed into complete, or even partial, process steps (e.g., 
service application components 90-2) that are performed in whole 
or in part on other Commerce Utility Systems 90, or any other 
5 system (including end user systems) selected by the participants in 
a given scenario. 



Example Commerce Utility System Types 

Financial Clearinghouse 200 

1 0 Figure 1 8 shows an example of a Financial Clearinghouse 

Commerce Utility System 200. "Financial Clearinghouses" 
support automated, efficient financial fulfillment for electronic 
transactions. For example, financial clearinghouse 200 may 
collect payment related information and details, and efficiently 

1 5 arrange for the transfer of money and other compensation to 
ensure that value providers get paid, including the automated, 
selective disaggregation of a payment into payment portions 
directed to appropriate value chain participants. Financial 
clearinghouses 200 may also provide credit, budgets limits, and/or 

20 electronic currency to participant (e.g., end-user) protected 

processing environments, wherein the financial clearinghouse may 
have distributed some of its operations to such protected 
processing environments for secure, local performance of such 
operations. The following are some example financial clearing 

25 support functions that can be provided through the use of the 
present inventions: 
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Clearing of financial transactions in a secure, 
efficient, timely and accurate manner. 

Providing secure financial clearing on payment 
mechanisms that are trusted by, and convenient for 
value providers and users/consumers. 

Assuring payment to rights holders and other value 
chain participants (for example, providers who supply 
value to the electronic community in some part of the 
process from creation, to distribution, to sale, and to 
delivery) without requiring them to take on the task 
of managing a large number of financial interfaces 
with widely dispersed customers and/or a variety .of 
often complex financial services standards and 
protocols. 

Allowing content consumers to pay for information 
goods and associated services using a variety of 
different payment vehicles via a common, trustable 
interface. 

Allowing each party involved in a transaction to 
. verify that a given exchange has occurred as it was 
mutually intended, and to preclude repudiation of the 
transaction by any party. 

Reconciling accounts at time of purchase or usage 
reporting (e.g., transferring funds from a value chain 
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participant account to one or more provider 
accounts). 



• Supporting frequent and granular transaction clearing 
activities. 

5 • Providing financial clearing services to all value 

chain participants (e.g., buyers, distributors and 
sellers of digital content of all kinds as well as 
buyers, distributors, and sellers of physical goods and 
user of other services). 

10 • Interfacing distributed electronic commerce domains 

with existing electronic, paper and/or other payment 
and/or clearing services, including but not limited to 
credit card systems, bank debit card systems, smart 
card systems, electronic data interchange, automatic 

15 clearinghouses, digital money, etc. 

• The effecting, by one or more banks and/or other 
organizations, of settlement and reconciliation and/or 
interfacing directly with entities who may legally 
perform settlement services. 

20 . • The effecting of the creation of, and assigning of, 

identifying labels, numbers, names or other unique 
identifiers, by one or more banks and/or other 
organizations to digital process and/or digital 
information creators, information distributions and/or 
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modifiers, and/or customer and/or other user accounts 
for funds, credits and debits. 

Using secure containers in any step, part, or process 
of providing secure financial clearing services. 

Controlling secure financial clearing processes based, 
at least in part, on rules and controls stipulating the 
distribution of processes to be performed at each 
protected processing environment of a distributed 
financial clearinghouse systems, e.g., clearing 
performed by the user protected processing 
environments, web servers, centralized clearing 
facilities. 

Efficiently and securely handling conversions from 
one currency to another. 

Enabling payment fulfillment on provision of other 
consideration including service fees, product fees 
and/or any other fees or charges based at least in part 
on content, process control, and/or rights 
management use. 

Supporting wide use of micro-fees and micro- 
payments at least in part based on content, process 
control, and/or other usage transactions, wherein said 
support may include the distributed, secure 
accumulation and/or processing of micro-transaction 
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activity and the periodic passing of information 
related to such activity through a clearinghouse 
network for further processing and/or accumulation. 

Efficiently measuring and managing micro-payment 
activity while minimizing transaction overhead. 

Minimizing latency in micro-payment transaction 
handling. 

Aggregating or "bundling" transactions against local 
value store or other payment vehicles (methods). 

Employing value chain rules and controls and chain 
of handling and control for efficiently administrating 
the disaggregation (splitting apart) of payments, 
including the assignment or transfer to different value 
chain providers of payments based on the same or 
differing electronic control sets controlling usage 
and/or other permissions (e.g., securely controlling 
payment consequences through the parsing of 
payment amounts among various value chain parties 
as required by rules and controls before specific 
payment methods are activated. 

Reducing (e.g., minimizing) the number of electronic 
messages required to support a given set of electronic 
transactions through, for example, distributed 
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transaction processing and/or transaction activity 
accumulation. 

Supporting local aggregation (bundling or combining 
together) of multiple payments or micro-payments at 
a value chain participant's site. 

Allowing value providers (e.g., value chain 
participants) to efficiently check another value chain 
participant's ability to pay before providing services 
or goods (physical and/or electronic) on credit. 

Allowing value providers to authorize an appropriate 
level of funding for estimated purchase levels on a 
value chain participant's preferred payment vehicle, 
including, for example, allowing the provision of 
budgets for credit and/or currency that can be 
expended towards all and/or only certain classes of 
transactions (e.g., content and/or process control 
types) including, for example, budgets for 
disbursement for expressly specified categories of 
expenditures such as only G and PG movies. 

Providing verification of the identity of a potential 
value chain participant and binding of that identity to 
the value chain participant's selected payment 
vehicles). 
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Providing periodic reporting of transaction activity 
for clearinghouse reconciliation and recordation 
purposes. Performing auditing, billing, payment 
fulfillment and/or other consideration and/or other 
clearing activities. 

Providing event driven reporting based, for example, 
on time, place, depletion of local funds, and/or class 
of disbursement activity such as purpose (for 
business, entertainment, travel, household expense), 
family member or other individual or group identity, 
category of content or other goods and/or services 
acquired, and/or category any of type of disbursement 
activity 

Receiving authority from secure chain of handling 
and control embodied in electronic control sets. 

Granting authority and/or providing services to, 
and/or in conjunction with, one or more distributed 
financial clearinghouses that are some combination of 
subordinate to, and/or have peer-to-peer relationships 
with, one or more of said clearinghouses. 

.Distributing financial clearing functions across a 
network or other system (for example, every 
consumer or other value chain participant node can 
perform distributed financial clearing services and 
wherein said participant node may communicate 
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financial clearing information directly to one or more 
other participants) and in accordance with rules and 
controls and other VDE techniques as described in 
the Ginter, et al patent specification. 

Granting authority and/or providing services to, or in 
conjunction with, one or more financial sub- 
clearinghouses whose operations may be located 
logically and/or physically elsewhere, such as within 
a company or government agency and/or within one 
or more jurisdictions and/or serving subsets of the 
overall business focus area of a senior financial 
clearinghouse. 

Distributing and/or otherwise authorizing financial 
clearing functions across a system or network, for 
example, where every consumer and/or certain or all 
other value chain participant nodes can potentially 
support a distributed usage clearing service initiating 
its own, secure financial clearing transactions and 
function in the context of the overall clearinghouse 
network including clearinghouse interoperation with 
one or more other participant, interoperable nodes, 
and as elsewhere in this list, all activities employing 
VDE techniques as appropriate. 
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Efficiently calculating, collecting, and dispersing 
sales and "value added taxes" imposed by at least one 
jurisdiction. 

Supporting a web of financial clearinghouses in 
which one or more classes (groups) of clearinghouse 
have interoperable, peer-to-peer relationships and in 
which, differing groups may have differing rights to 
interoperate with members of other groups, for 
example financial clearinghouses on end-user 
protected processing environments may have limited 
rights to inter-operate with "primary" financial 
clearinghouses. 

Supporting a web of clearinghouse protected 
processing environments in which such protected 
processing environments comprise discreet "banks" 
or banking protected processing environments, and 
where such protected processing environments can 
employ VDE capabilities to securely govern and 
perform banking functions such as the secure storage 
(locally and/or remotely) of notational currency, the 
right to "lend" stored currency to end-user and/or 
other clearinghouse protected processing 
environments, the right to launch electronic currency 
objects, the right to fulfill payment from local or 
remote currency store(s), the ability to receive 
communications representing obligations to pay (e.g., 
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electronic bills), the ability to fulfill such payments, 
and the ability to operate as a component banking 
"branch" of one or more virtual bank(s) (or banking 
network(s)) wherein such bank performs many of the 
roles currently performed by conventional banks. 

Supporting the ability for financial clearinghouses to 
create electronic currency that is conditionally 
anonymous and where such currency may be 
employed in the fulfillment of payment obligations 
and where such currency is treated as authentic . 
without the requirement that a receiving party connect 
after such receipt with a remote banking authority for 
assessing that the currency is valid or authorized for 
use. 

Supporting the ability for distributed clearinghouse 
protected processing environments to operate - in 
conjunction with one or more capabilities described 
above — on portable devices such as smart cards (e.g., 
electronic wallets, etc.) where cellular or land-line 
communication means (or other transport 
mechanisms) support on-line or asynchronous 
communication of information related to a current or 
an plural transactions such as billing or other audit 
information regarding commerce activity including 
identification, for example, of purchasers, sellers, 
and/or distributors, and authorization information, 

113 



PCT/US96/14262 

budget information, credit provision, currency 
provision, and/or disbursement information, etc. 
related to such activity. 

Supporting the provision of discounts, subsidies 
and/or coupons to value chain participants, for 
example to consumer users, in exchange for usage 
data or more finely grained usage data (for example, 
ameliorating privacy concerns in some contexts). 

May be organized hierarchically, peer-to-peer, or in a 
combined mode where responsibility for financial 
clearing may be distributed in differing fashions for 
differing commerce models and/or activities and/or 
value chains and where certain one or more parties 
may be, for example, hierarchically more senior to 
other parties in one or more instances and 
hierarchically a peer or less senior in one or more 
other instances. 

The relationship among participants is programmable 
and may be set (and later modified) to represent one 
or more desired financial clearing arrangements for 
given commerce activities, value chains, or models. 

Distributing payments to plural parties, including, for 
example, taxes to one or more governments (e.g., 
city, state, and federal). 
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Figure 18 shows an example function oriented diagram for 
financial clearinghouse 200. In this example, financial 
clearinghouse 200 is highly automated, and operates in a trusted, 
secure domain to provide a protected processing environment. It 
5 efficiently provides financial clearing services to all kinds of 
electronic commerce chains. It can also serve as a gateway 
between the highly secure virtual distribution environment (VDE) 
domain and other domains — providing protocol support for the 
existing infrastructure. The gateway functions can allow the 

10 highly flexible and distributed VDE protected processing 
environments to exploit the inflexible and centralized, but 
ubiquitous and trusted, existing financial infrastructure services. 

The core functions of financial clearinghouse 200 relate to 
payment processing 208, payment aggregation 212, payment 

1 5 disaggregation 2 1 4, and micro-payment management 2 1 6 since 
these functions collect money from customers and other value 
chain participants, and pay money to value chain service or 
product providers such as merchants. 

In more detail, financial clearinghouse 200 may perform the 

20 following functions in this example: 

• payment processing 208, 

• credit checks 210, 

• payment aggregation 212, 

• payment disaggregation 2 1 4, 
25 • micro-payment handling 2 1 6, 
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• event driven reporting 218, 

• reconciliation 220, 

• database maintenance/management 222, 

• replication 224, and 

5 • propagation 226. 

Financial clearinghouse 200 may receive payment 
information 202, customer information 230, provider information 
232, and aggregated reports and bills 234 from the outside world. 
It may generate debit orders 236, credit orders 238, statements and 

1 0 reports 204, 240, release signals 242, and credit checks and 
authorizations 244. 

Database management 222 and event driven reporting 2 1 8 
may be used to securely provide accurate financial reports to value 
chain participants. Reconciliation function 220 — which is related 

15 to both reporting and financial management — allows financial 
clearinghouse 200 to provide more reliable financial management. 
Replication function 224 and propagation function 226 are used 
by financial clearinghouse 200 to facilitate distributed processing 
with other financial clearinghouses 200 and/or other secure or 

20 insecure protected processing environments, permitting the 
financial clearinghouse to securely share state and update 
information with other Commerce Utility Systems or other 
participants. 

In the example shown, the payment information 202 (which 

25 may arrive in one or more secure containers 1 52) is the primary 

input to payment processing block 208. If desired, payment 
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information 202 can also include some or all of the usage 
information sent to a usage clearinghouse 300 - or it may include 
different types of usage information more relevant to financial 
auditing and transaction tracking. This payment information 202 
can arrive in real time or on a delayed (e.g., periodic or other 
event-driven) basis. 

Financial clearinghouse 200 uses provider information 232 
and customer information 230 to effect funds transfers between 
customers and providers. Financial clearinghouse 200 uses 
aggregated reports and bills 234 to guide the overall payment 
processing 208 as well as payment aggregation 212 and payment 
disaggregation 214. For example, financial clearinghouse 200 
may issue debit and credit orders 236, 238 to third party financial 
parties such as banks, credit card companies, etc., to effect 
debiting of consumer accounts and corresponding crediting of 
provider accounts. Financial clearinghouse 200 may issue 
statements 204 and reports 240 for secure auditing and/or 
informational purposes. Financial clearinghouse 200 may issue 
credit authorizations 244 after performing credit checks 210, 
thereby extending credit to appropriate value chain participants. 
Such authentication 244 may include an input/output function, 
unless they are performed entirely locally (i.e., an authorization 
request comes in, and clearinghouse 200 is the source of credit 
and/or credit limit information). 

Financial clearinghouse 200 may issue release signals 242 
in appropriate circumstances to allow electronic appliances 100 to 
stop maintaining and/or keep "pending** financial information 
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after it has been transferred, analyzed and/or processed by 
financial clearinghouse 200. In one example, the user appliance 
100 may, within business model limitations, store the financial 
information even after it is "released," reduce it to a summary, etc. 
5 Of course, it may have already done this with a copy of the data 
(e.g., if previously allowed to access it). For example, suppose the 
local copy of financial usage information contains confidential 
business model information. A property might cost $1 .00 to view, 
and that dollar may be split among several parties. Normally, the 

10 user is only aware of the overall bottom line, not the details of the 
split — even though a record may exist locally for each of the 
participants in the transaction. 

Figure 19 shows an example architectural diagram for 
financial clearinghouse 200. Financial clearinghouse 200 in this 

1 5 example includes a secure communications handler 246, a 

transaction processor 248, a database manager 250, a switch 252, 
and one or more interface blocks 244. This example financial 
clearinghouse architecture may be based, for example, on the 
operating system architecture shown in Figure 12 and 13 of the 

20 Ginter et al. patent specification (general purpose external services 
manager 172 in that example could support settlement service 
interfaces 254 for example). Secure communications handler 246 
allows financial clearinghouse 200 to communicate securely with 
other electronic appliances 100(1) .. . 100(N). Such 

25 communications may be by way of secure digital containers 1 52. 
It is desirable for most Commerce Utility Systems 90 (including 
financial clearinghouse 200) to support both real time and 
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asynchronous receipt of containers 152. In addition, financial 
clearinghouse 90 may also support a real time connection protocol 
that does not require containers 152 for simple transactions such 
as making a credit card payment that doesn't have disaggregation 
5 requirements. The advantage to using a real time connection is 
real time results. This may be beneficial in circumstances where 
users need more money or credit because they have run out (rather 
than simply making a report or receiving a periodic replenishment 
of a budget that has not been exhausted), and also when a provider 

1 0 (e.g., of content or budget) insists on clearing a transaction before 
allowing whatever activity initiated the transaction to go forward ■ 

A connection for a real time transaction doesn't always 
require secure containers 152, but using containers 152 even in 
this scenario has advantages. For example, containers 1 52 permit 

1 5 attachment of rules and controls to the contents, allowing users to 
specify how the contents may be used. In addition, use of 
containers 152 leverages existing capabilities in the protected 
processing environment. Using a technique such as electronic 
mail to deliver containers 152 (e.g., as attachments to SMTP mail 

20 messages, or as attachments to any other e-mail protocol that 
supports attachments) permits asynchronous processing of 
contents* thereby allowing Commerce Utility Systems 90 to 
smooth out their peak processing loads. A cost of operating a 
commercial clearinghouse is the depreciation expense of the 

25 equipment The amount of equipment is principally driven by the 
peak load requirement. One can expect a significant variance in 
load (for example, compare Friday night at 8 pm versus Tuesday 
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morning at 3am). Smoothing out this function can lead to quite 
considerable savings in equipment and related costs (electricity, 
personnel, maintenance, etc.) 

Transaction processor 248 may process and analyze 
received information, and database manager 250 may store 
received information in a database for later analysis and/or for 
historical analysis (to increase credit limits, analyze payment 
histories, etc.) In addition, database manager 250 may also store 
information associated with existing credit limits, addresses for 
communications (physical and/or electronic), and other account 
information. For example, the Ginter et al. patent specification 
discusses budget encumbrances. The database manager 250 may 
be used to store information used to track encumbrances as well. 
There may also be sets of security information used to 
communicate with protected processing environments and/or users 
employing the protected processing environments, and the 
settlement services. Records associated with communications 
with the settlement services may also be stored there as well. The 
database 250 may also be outfitted with various reporting facilities 
related to its contents. 

Transaction processor 248 and database manager 250 
together perform most of the functions shown in Figure 1 8. 
Switch 252 is used to route information to and from interface 
blocks 244. Interface blocks 244 are used to communicate with 
third party settlement services, such as credit card companies, 
Automatic Clearing House (ACH) systems for bank settlements, 
debit card accounts, etc. Optionally, the internal settlement 
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services provided by a Federal Reserve Bank 256 may be used in 
lieu of or in addition to the third party settlement services shown 
to provide settlement of accounts in accordance with prevailing 
banking arrangements and legal requirements. The payment 
5 mechanisms used by financial clearinghouse 200 may be 
symmetrical (e.g., tell VISA to charge consumer A's charge 
account and credit vendor Y's account) or asymmetrical (e.g., tell 
VISA to debit consumer A's charge account and provide the 
money to the financial clearinghouse which will credit vendor Y's 
1 0 account using some other payment mechanism) as allowed by 
applicable financial and banking regulations. 

Example Financial Clearing Processes 

Figure 20 shows an example financial clearinghouse 

15 process. In this example, a provider 164 provides goods, services 
or content to a consumer 95. For example, provider 164 may 
provide one or more digital properties 1029 and associated 
controls 404 within an electronic secure container 1 52. A secure 
protected processing environment 154 at the consumer 95 site 

20 keeps track of payment, usage and other information, and may 
provide an audit trail 228 specifying this information. Audit trail 
228 may be transmitted from the site of consumer 95 to financial 
clearinghouse 200 within one or more secure containers 1 52b. 
Audit trail 220 might include, for example, the identification of 

25 the reporting electronic appliance 100; the amount of payment; 
provider identification; the consumer's desired payment method; 
the name or other identification of the electronic appliance user; 

121 



and the type(s) of transaction(s) involved. The time and/or 
frequency of reporting might be based on a number of different 
events such as for example, the time of day, week, month, year or 
other time interval; the occurrence of some related or unrelated 
event (e.g., pre-approval for a purchase is required, a certain 
number of purchases have taken place, a local electronic purse has 
been exhausted of funds, reporting is necessary for some other 
reason, etc.); or a combination of these. 

Financial clearinghouse 200 analyzes the audit trail 228, 
and generates one or more summary reports 240. Financial 
clearinghouse 200 may provide the summary report 240 to 
provider 164 by transmitting it electronically within a secure 
container 152c. Financial clearinghouse 200 may also coordinate 
with a financial intermediary 258 and one or more financial 
processors 260 to effect a debiting of a bank or other account 
owned by consumer 95 and corresponding crediting of a bank or 
other account owned by provider 164. 

For example, the financial clearinghouse 200 may receive 
the audit information, disaggregate the transactions (into value 
chain amounts for creators, distributors, and others; as well as for 
tax authorities and other governmental entities), and then calculate 
an amount due it from each of the transaction beneficiaries. Then, 
if desired or necessary (due to the size of the transactions, per 
transaction fees, or other efficiency and/or cost considerations), 
the transactions may be rolled up into lump sums for each of the 
parties, and submitted to a financial intermediary 258 (along with 
appropriate account information) that is responsible for 
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performing credit card transactions. The financial intermediary 
258 (who may also charge a fee or take a percentage) may then 
cause transactions to occur at the financial processor 260 such that 
the beneficiaries each receive the appropriate amounts. 
5 Alternatively, if the financial clearinghouse 200 has the ability and 
authorizations necessary to submit credit card transactions directly 
to credit card companies, it may cause the transactions to occur 
directly with the financial processor 260 (e.g., Visa). 

Financial processor 260 may send a statement 204 to 

10 provider 164 (and/or to consumer 95) detailing the financial debits 
and payments that have occurred. It may provide statement 204 ' : 
within a secure container (not shown) if desired. Financial 
clearinghouse 200 may receive a portion or percentage of the 
debited funds to compensate it for the financial clearing services it 

1 5 has provided. 

Figures 20A-20F show an example financial clearing 
activity using a local electronic money purse 262 maintained at the 
consumer's electronic appliance 100. In this example, financial 
clearinghouse 200 may initially provide consumer 1 00 with 

20 electronic money in the form of electronic cash by transmitting the 
electronic cash within one or more secure containers 1 52. 
Financial clearinghouse 200 may automatically debit the 
consumer's bank 206a or other account to obtain these funds, and 
may do so at the consumer's request (see Figure 20A). 

25 The consumer's electronic appliance 100 upon receiving the 

electronic funds may deposit them within an electronic cash purse 
262 it maintains within its protected processing environment 154 
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(e.g., as an "MDE" described in Ginter et al.) (see Figure 20B). 
The customer's electronic appliance 100 may use this locally 
stored electronic money to pay for goods and services consumed 
by the consumer. For example, a publisher 68 may provide a work 
5 1 66, such as a book, film, television program, or the like, to the 
consumer's electronic appliance by transmitting it within one or 
more secure containers 152b. The consumer may operate his or 
her electronic appliance 100 to open the container and access the 
work 166, allowing the consumer to use the work in the manner 

1 0 specified by its associated electronic controls (see Figure 20C). 

Assuming that the rights owner requires payment in return 
for usage of the work 166, the consumer's electronic appliance 
100 may automatically debit electronic purse 262 by the amount 
of payment required (in this case $5) (Figure 20C). Additionally, 

1 5 electronic appliance 1 00 may automatically generate a usage 

record 264 recording this usage event. Based on time and/or other 
event occurrence, the consumer's electronic appliance 1 00 may 
automatically send an audit trail 264 — which may comprise a 
package of audit records transmitted at audit time or set of related 

20 records stored in the secure database — (or a summary of it to 
protect the consumer's privacy) — to financial clearinghouse 200 
in the form of one or electronic containers 152c (see Figure 20D). 

Upon receiving the usage record 262 and successfully 
storing it within its own database 250, financial clearinghouse 200 

25 may send a release signal 242 within an electronic container 1 5 2d 
(see Figure 20D). This release signal 242 may allow the 
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consumer's electronic appliance 100 to delete the usage record 
264 it had previously maintained (see Figure 20D). 

The consumer may use the same or different work 1 66 again 
to prompt generation of an additional usage record 264' and to 
5 decrement the electronic purse 262 by another usage charge (in 
this case exhausting the purse's contents) (see Figure 20E). 
Exhaustion of electronic purse 262 may prompt the consumer's 
electronic appliance 100 to again contact financial clearinghouse 
200 to request additional funds (see request 228') and to also 

1 0 provide usage record 264' (both pieces of information are 
transmitted within the same electronic container 1 52e in this 
example) (see Figure 20F). 

Financial clearinghouse 200 may respond by transmitting 
additional electronic funds (after debiting the consumer's bank or 

1 5 other account), and may also provide another release signal 

allowing the consumer's electronic appliance 100 to delete usage 
record 264' (see Figure 20F). The money collected may be paid to 
the rights holders (after any appropriate reductions to compensate 
Commerce Utility Systems 90). 

20 Payment Disaggregation 

Figure 21 shows an example financial clearing activity 
involving value chain "disaggregation." Financial clearinghouse 
200 in this example efficiently, reliably and securely supports 
payment disaggregation within a value chain. Figure 21 shows a 
25 content creator, such as an author, delivering a work 1 66 to a 
publisher 1 68. The publisher publishes the work (for example, 
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within an electronic book 166') and delivers it to a consumer 95. 
In this example, the consumer 95 pays $20 for his copy of the 
book 166'. The consumer's payment is "disaggregated" or split 
up between the author 164 and the publisher 168 based, for 
5 example, upon a contractual agreement. In this example, the 
publisher receives four of the consumer's $20 and the author 
receives the rest. 

Disaggregation allows financial clearinghouse 200 to 
automatically split up a consumers' payment among any number 

1 0 of different value chain participants. This is extremely useful in 
ensuring that all contributors to a product or service can reliably 
and efficiently receive compensation for their respective 
contributions. 

Figure 22 shows how financial clearinghouse 200 can 

1 5 support the value chain disaggregation shown in Figure 21. In the 
Figure 22 electronic example, the customer c 95 may deliver his 
payment electronically to financial clearinghouse 200. This 
payment may be in the form of electronic currency packaged 
within a secure electronic container 1 52a, or it might be in some 

20 other form (e.g., reported usage information coupled with a 

preexisting authorization for financial clearinghouse 200 to debit 
the bank account of customer 95). 

Financial clearinghouse 200 may distribute appropriate 
shares of the customer's payment to author 164 and publisher 168 

25 in accordance with the agreement between the author and the 
publisher. What tells financial clearinghouse 200 who should 
receive the disaggregated parts of the payment? In this Figure 22 
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example, the work 166 may pass from the author 1 64 to the 
publisher 168 and from the publisher 168 to customer 95 in 
electronic form within one or more secure electronic containers 
152. One or more electronic control sets 188 may be included 
5 within the same or different containers, these control sets being 
associated with the work 166 or other property. Control sets 1 88 
may specify, among other things, the amount of payment customer 
95 must supply in order to be able to use the work 166. 
Controls 188 may also specify and control how the 

1 0 customer's payment will be disaggregated among the other value 
chain participants. For example, author 164 may specify within v 
controls 1 88b the author provides, that she is to receive $16 for *- 
each copy of work 166 purchased by an ultimate consumer 95. 
Because of the secure chain of handling and control provided in 

1 5 accordance with the virtual distribution environment (see the 

Ginter et al. patent disclosure), author 1 64 can be confident (to the 
degree required by the commercial priorities of the author and 
allowed by the strength of the overall system) that publisher 168, 
customer 95 and any other consumers or potential users of 

20 property 166 will be subject to this control 1 88b. The publisher 
168 may add its own controls to the one specified by author 164, 
the publisher controls 1 88c providing a $4 mark up (for example) 
that it will receive for the use of its brand name, distributing and 
marketing services. 

25 Figure 22A shows a detailed example of how payment 

disaggregation can be performed within the customer's protected 
processing environment 154 using control sets 188 as described in 
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the Ginter et al patent disclosure. Ginter et al. teaches, in Figure 
48 and associated text, how a control set can implement and 
control an overall metering, billing and budgeting process within a 
user's protected processing environment 154. Figure 22A 
illustrates payment disaggregation based on one or more control 
sets 188 provided to a consumer's protected processing 
environment 154. Each of the processing blocks shown in Figure 
22A may be in response to a user request (event) to open and 
access content. 

In this particular example, a metering method 275 is 
designed to pass an event to billing method 277 whenever the 
consumer first uses a particular piece of content (meter event 275 
could also or alternatively pass the event along each time the 
consumer uses the content to provide a "pay per view" 
functionality if desired). 

The billing methods 277 include two different billing 
methods 277a and 277b in this example. Methods 277a, 277b can 
be independently deliverable — for example, the author 164 could 
deliver billing sub-method 277a, and the publisher 168 could 
deliver billing sub-method 277b. Billing method 277a writes 
information to a billing trail data structure specifying how much 
the author 164 is to be paid (SI 6 in this example). Billing method 
277b writes information to the same or different billing trail data 
structure specifying how much the publisher is to be paid ($4). 
Billing methods 277a, 277b may each receive the open event 
passed along by meter method 275, and may each write billing 
records to the same (or different) billing trail data structure. 
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In this example, a budget method 279 may be delivered 
independently of the billing methods 277a, 277b. Budget method 
279 may write records to a budget trail data structure 28 1 
specifying (among other things) the payment disaggregation 
5 arrangement (i.e., the $ 1 67$4 split between author and publisher) 
specified by the billing methods 277a, 277b. The budget trail data 
structure 28 1 (which is maintained independently from the data 
structures maintained by billing methods 277a, 277b and therefore 
cannot be compromised by the author 164 and/or the publisher 

10 168) might be sent to a financial clearinghouse 200. The financial 
clearinghouse 200 would perform payment and debit financial . -. 
clearing as described above to result in the consumer's account - 
being debited by $20, the author's account being credited by $16 
and the publisher's account being credited by $4 (thus 

1 5 disaggregating the user's $20 payment between the author 1 64 and 
the publisher 168). Meanwhile, the billing trail data structure 
could be sent to a usage clearinghouse 300 specified by the author 
164 and/or the publisher 168. Usage clearinghouse 300 could 
analyze the billing trail data structure and let author 164 and/or 

20 publisher 168 know what payments they might expect to receive 
from the financial clearinghouse 200. 

Thus, in this example, electronic control sets 188 may 
specify or define, among other things: (i) rights available in a 
particular digital object, (ii) the cost of exercising such rights, and 

25 (iii) how payments for exercising rights will be divided 

(disaggregated) among rightsholders. This ability to define 
payment disaggregation in advance (before customers' payment 
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methods and arrangements are activated) provides a high degree of 
efficiency and flexibility - since it can use the consumers' 
payment method, for example, to automatically direct parts of the 
consumers' payment to appropriate people who need to be 
5 compensated. Since the same electronic appliance 1 00 that is 
being used to exercise the rights is also being used to help direct 
payments to various different value chain participants, a portion of 
the overall financial clearing process is effectively distributed 
throughout a large number of parallel computing resources. 

1 0 Because of the high degree of trustedness that can be provided by 
the system disclosed in the Ginter et al. patent specification, for 
example, rightsholders can release such control sets 1 88 into the 
stream of commerce with an appropriate that their payment 
arrangements will be carried out. Financial clearinghouse 200 can 

1 5 help to ensure that such disaggregated payments efficiently and 
rapidly reach their required destinations. 

A protected processing environment 1 54 at the site of 
customer 95 securely enforces the augmented controls 1 88c, 
requiring total payment and/or payment authorization from the 

20 customer 95 before allowing the customer to access work 1 66. 
Controls 188c may also specify which financial clearinghouse 200 
is to be used to handle payment processing, and what payment 
methods are acceptable while still giving customer 95 flexibility in 
terms of choosing a desired payment method. The customer's 

25 protected processing environment 1 54c may then automatically 
send appropriate payment or payment authorization 190a to 
financial clearinghouse 200 for disaggregation in accordance with 
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controls 188a — which may be the same controls (or a subset of 
those controls relating to payment disaggregation) specified by the 
author and/or the publisher. 

Because the customer's protected processing environment 
154c generates controls 1 88a subject to the controls 1 88c, 1 88b 
specified by the publisher and author (see Figure 22), these 
payment controls 1 88a can be trusted to carry out the payment 
wishes of the author and the publisher and to reflect the payment 
dividing agreement between the two of them. The customer's 
protected processing environment 154c may send the customer's 
payment or payment authorization 1 52a and these payment 
controls 188a to financial clearinghouse 200 within one or more 
secure electronic containers 1 52a. 

Financial clearinghouse 200 processes the payment or 
payment authorization 152a in accordance with controls 188a, 
distributing payment 152b to the publisher and payment 152c to 
the author in accordance with the payment dividing agreement 
reached between the author and the publisher. Thus, for example, 
financial clearinghouse 200 might send $4 of electronic money to 
the publisher and $16 of electronic money to the author, or it 
might credit the bank or other accounts of the author and publisher 
in these amounts. Because this entire process takes place in a 
secure, trusted virtual distribution environment, each of the value 
chain participants can trust that they will in fact receive the 
payment they require and the process can be carried on 
automatically and electronically in a very efficient way that 
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flexibly accommodates a wide variety of different business models 
and ad hoc relationships. 

Figure 23 shows a further, somewhat more complex 
payment disaggregation example that adds a content distributor or 
5 aggregator 1 70 to the value chain. In this example, the consumer 
95's $20 may now need to be split three ways instead of two, with 
the author 164 still receiving $16, the publisher receiving only $3 
and the content distributor/aggregator 170 receiving $1 for his or 
her efforts. Figure 24 shows that the same basic arrangement 

1 0 shown in Figure 22 can be used to accommodate the payment and 
other interests of this new value chain participant. 

Figure 25 shows a further payment disaggregation example. 
Figure 25 shows how disaggregation can be used to compensate 
Commerce Utility Systems 90 for their role in maintaining and 

1 5 managing the value chain. As described above, the Distributed 
Commerce Utility 75 provides very important services, such as 
financial clearing, usage auditing, permissioning, certification, etc. 
Entire businesses or industries may be based on efficiently and 
reliably providing these kinds of administrative and support 

20 services. Commerce Utility Systems need to be compensated for 
their own investments and efforts. One way for them to be 
compensated is to receive a small part of every transaction - "a 
piece of the tick." The same payment disaggregation mechanisms 
described above can also be used to support such micropayments 

25 to Commerce Utility Systems 90. 

Figure 23 shows one example in which the Commerce 
Utility Systems 90 receive 3% (e.g., $0.60 in the example shown) 
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of the value of each transaction. Because electronic control sets 
188 discussed above can be used to implement such micro- 
payment capabilities, any desired business arrangement or 
objective can be flexibly and efficiently accommodated. 

Figure 26 shows that payment disaggregation can be used to 
disaggregate or split up a single consumer payment into an 
arbitrary number of different amounts (even recording amounts in 
different types of currencies for international trading purposes) at 
a variety of different destinations and using a variety of different 
payment mechanisms (e.g., credit cards, bank accounts, electronic 
money, etc.). 

Figures 27 and 28 show still additional payment 
disaggregation examples to further illustrate the flexibility in 
which Distributed Commerce Utility 75 can handle these and other 
arrangements. The Figure 27 example shows the customer's 
payment being split up among the author 164, the publisher 168, 
the aggregator 170, a repackager 174 and two additional authors 
164a, 164b supplying additional works incorporated within the 
electronic property being provided to the customer. The Figure 27 
example is particularly applicable, for example, where the 
repackager 174 takes content from several sources on related 
matters and. combines them into mixed source products such as 
multimedia combinations, "current awareness" packages, or 
newsletter-like publications for sale to interested parties. 

For example, repackager 174 might publish a newsletter on 
contemporary politics, and select an essay written by author 164 
for publication along with two other works written by authors 
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164a, 164b for publication in the next newsletter issue. Authors 
164, 1 64a and 164b may grant repackager 1 74 the right to 
reformat and redistribute the work. Taking advantage of this 
reformatting right, repackager 174 may create the latest issue of 
the newsletter and distribute it in a secure electronic container for 
reading by customer 95. In this example, the secure electronic 
container 152a may contain at least four separately "delivered" 
sets of business requirements — one for each of the three works (as 
specified by each of author 164, author 164a and author 164b) and 
one for the overall newsletter (as specified by repackager 1 74). 
Alternatively, the various works and/or the controls applying to 
them can be sent and delivered in independent secure containers 
1 52, and/or some or all of the works and/or controls may be 
located remotely. 

To read the newsletter, customer 95 opens electronic 
container 152a. Suppose that the newsletter cost (as set by 
repackager 174) is $10 per issue. The customer's $10 payment or 
payment authorization is sent to financial clearinghouse 200, 
which resolves it to give each value chain participant 
compensation (for example, author 164 may get $1, publisher 168 
may get $1, aggregator 170 may get $.50, each additional author 
164a, 164b may each get $1 and the repackager 1 74 may get the 
rest ~ all as directed by the applicable electronic controls. Thus, 
the repackager can be compensated for selecting appropriate 
articles on the topic and combining them in a single, easy to read 
publication, and may also bring its own brand name recognition as 



134 



wu ya/ituai 



an indicator of overall quality, and may itself add unique content 
of its own creation. 

Figure 28 shows a "superdistribution" example. One key 
rights holder concern is copyright infringement from "pass-along" 
5 — that is, illegal duplication and redistribution. This pass-along 
problem is serious in digital environments such as the Internet. 
The virtual distribution environment disclosed in the Ginter et al. 
patent specification and the administrative and support services 
arrangements disclosed in this specification fundamentally 

1 0 transform pass-along from a clear threat to an important 

opportunity. Because of the unique, automated, secure electronic 
management of value chain rights provided by the virtual 
distribution environment in the preferred embodiment, the 
consumer can be treated as a trusted member of the value chain. 

1 5 This makes possible a superdistribution model in which all 
customers become potential distributors. Since revenue from 
superdistribution incurs only minimal rights holder costs, 
superdistribution provides large profit potentials to holders of 
rights in successful works. 

20 Looking at Figure 28, assume that customer 95 received a 

work from aggregator 170 that she likes so much that she wants to 
pass it along to several friends and colleagues. Assuming that 
aggregator .170 has granted customer 95 the right to redistribute 
the work, the customer may simply and easily be able to send a 

25 copy of the work to each of any number of additional potential 
customers 95(1) .. . 95(N). These additional people may know 
customer 95 and believe that she would not be sending them 
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something that was not potentially interesting and of high quality. 
In addition, the downstream customers may be able to read an 
abstract or see extracts of the work (e.g., view a trailer of a film, 
read the first chapter of a novel, or the like) without triggering 
5 payment. 

After reading the abstract or watching the first five minutes 
of the film without cost, suppose six of the downstream customers 
95(3)-95(8) agree to pay for the content at an example cost of 
$3.25 each. Financial clearinghouse 200 may ensure that the 

10 author 1 64, publisher 1 68 and aggregator 1 70 each receive an 
appropriate share of the income (e.g., $7 to the author, $7 to the 
publisher and $8.75 to the aggregator). 

Superdistribution makes possible any number of levels of 
redistribution. For example, suppose that of the six downstream 

1 5 customers 95(3)-95(8), three of them decide to pass the work 
along to each of six additional potential customers — so that 
eighteen additional people receive a copy. Since the redistributed 
works have associated control structures mandating the same 
payment arrangement, author 164, publisher 168 and aggregator 

20 1 70 each receive additional payments from each of these new 
customers. The snowballing effect of redistribution can continue 
in this manner across any number of consumers for a long time, 
and can dramatically increase revenue with minimal additional 
cost to the value chain members. 

25 

Payment Aggregation or Bundling 
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Micro-fees and micropayments may become an important 
basis for content usage transactions. For example, a consumer 
might pay each time she views a particular work or uses a certain 
piece of computer software, or listens to a certain piece of music. 
5 Different payment arrangements can be flexibly provided so that 
the consumer might have the option of paying a larger initial fee " 
for unlimited usage or smaller micropayments on a per use basis. 
In addition, micropayments may be the least burdensome and most 
practical way for Commerce Utility Systems 90 to be compensated 
1 0 for their services. The ability to efficiently handle micropayments 
is thus very important in terms of supporting and enabling small - 
charges. 

Traditional financial payment mechanisms, such as credit 
cards, checks and the like, are unsuited to manage micropayments. 

1 5 These systems typically have levels of transaction overhead that 
impose severe burdens on business models based on many 
purchases below $5 each. For example, if it costs $0.50 to handle 
a payment transaction, it becomes uneconomical to handle 
payments for less than some value, perhaps $2 each because the 

20 cost of handling the payment is such a large portion of the 
transaction value, or even exceeds the payment itself. Hence, 
traditional financial payment mechanisms favor larger purchases 
and disfavor micro-purchases. 

Figure 29 shows how payment aggregation or bundling can 

25 be used to circumvent these concerns by reducing the number of 
individual financial transactions that need to be cleared, and/or by 
reducing the amount of messaging required to clear those 
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transactions. The example payment aggregation shown in Figure 
29 may be performed on the consumer's own electronic appliance 
1 00 within a protected processing environment 1 54; or at a 
centralized financial clearinghouse 200; or part of it can be 
5 performed at the appliance and part of it performed at the 

centralized clearinghouse. This payment aggregation process can 
aggregate or combine many small payments together into larger 
payments — or into a bundle of small payments that can be 
handled all at once. Such larger payments and/or bundles can be 

1 0 reported periodically along with other transaction data if desired to 
be reconciled and recorded by Distributed Commerce Utility 75. 
This ability to aggregate smaller payments has important 
beneficial effects in terms of increasing efficiency, reducing the 
number of individual transactions that need to be cleared, and 

1 5 decreasing messaging traffic over electronic network 1 50. Of 
course, payment aggregation is not necessarily suitable for every 
transaction (some large, critical or risky transactions may require 
real time clearing, for example), but can be used in a large number 
of routine transactions to reduce the burdens on Commerce Utility 

20 Systems 90 and overall system 50. 

In one variation on this concept, payment aggregation may 
preserve the amounts of each individual transaction to allow high 
degree of reporting granularity but may be used to trigger when 
reporting occurs (e.g., after X dollars have been charged, or Y 

25 number of transactions have occurred) so that many individual 
transactions can be bundled and transmitted/processed together. 
This type of aggregation is useful for reducing the number and 
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frequency of individual messages traveling over electronic 
network 1 50. In such instances, the reporting electronic appliance 
100 may report: (i) the sum of the aggregated individual 
transactions, or (ii) each of the individual transactions, or (iii) 
5 both, or (iv) a combination of the two. 

Figure 29 shows that a consumer may use his or her 
electronic appliance 100 for a number of different activities, such 
as, for example, reading a novel, watching a video program, 
obtaining and reviewing research results, interacting with and 

1 0 enjoying multimedia presentations, and home financial 

management such as checkbook balancing. A per use micro- 
payment may be associated with each of these activities. For 
example, the consumer might pay $1 to a publisher A and $1 .50 to 
an author A each time the consumer accesses an electronic version 

15 of a work written by the author and distributed by the publisher. 
Suppose that the author A's works have become so popular that 
they have been made into films. The consumer might pay on a 
per-use basis to watch one of these films — paying the publisher A 
$5, the author A $3 and Distributed Commerce Utility 75 $0.50. 

20 Payment aggregators 266 (which may, if desired, operate at 

the consumer's site within the protected processing environment 
154 provided by the consumer's electronic appliance 100) may 
aggregate payments to common entities, keeping a running total of 
the amount of money owed to publisher A, the amount of money 

25 owed to author A, and the amount of money owed to the 
Distributed Commerce Utility 75. This running total can be 
incremented each time the consumer triggers an additional 
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payment event. The aggregated payment amounts can be 
periodically or otherwise reported to financial clearinghouse 200 
or other Commerce Utility Systems 90 based on certain time 
intervals (for example, weekly, monthly, or daily), the occurrence 
5 of certain events (for example, the consumer has exceeded her 
credit authorization and needs a new one, certain electronic 
controls have expired, etc.), and/or a hybrid of any or all of these 
techniques. 

Figure 30 shows another example of payment aggregation 

1 0 across a number of consumer transactions. In this example, 

payments to the same value chain participants and using the same 
payment method are aggregated together to provide totals. This 
payment aggregation — which may take place at the consumer's 
site and/or within a financial clearinghouse — reduces the number 

15 of overall financial transactions that need to be cleared. This 
increases efficiency and throughput, and decreases the cost for 
handling each individual consumer transaction. 

Figure 31 shows a still additional payment aggregation 
example in which aggregation is performed over transactions of a 

20 number of different consumers. For example, all transactions 
using a particular payment method pertaining to a particular 
provider could be aggregated by a financial clearinghouse 200. 
Note that the payment aggregation techniques shown in Figures 
29-3 1 do not necessarily result in loss of individual transaction 

25 detail. In other words, it is still possible for consumer electronic 
appliances 1 00 to log and report detailed per-transaction 
information, and for financial clearinghouse 200 and/or the usage 
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clearinghouse 300 to report detailed usage information on a 
transaction-by-transaction basis - even though individual 
transaction payments are being combined for more efficient 
payment processing and handling. This ability to separately 
5 handle and process more detailed and granular usage information 
while at the same time aggregating payments can provide a high 
level of auditing accountability without unduly burdening the 
payment handling mechanism. In some cases, loss of the detail 
records leads to savings on the clearinghouse side. They may be 

1 0 discarded, but there are advantages to keeping them around on the 
user's system and/or in a repository on a Commerce Utility 
System 90. If there is a billing dispute, for example, the local- 
copy of the detail records might serve as useful evidence of what 
actually occurred - even if they were never transmitted to the 

15 clearinghouse. 

Figure 32 shows how an example financial clearinghouse 
200 might be modified to include a payment aggregator 
component 268. Payment aggregator 268 could be used to 
aggregate payments incoming from a number of different 

20 consumer electronic appliances 100 or other sources, and provide 
those aggregated payments to switch 200 for handling via third 
party settlement services, for example. Payment aggregator 268 
could selectively aggregate only certain payments while 
permitting other payments to pass through directly to switch 200 

25 for direct handling without aggregation. Payment aggregation can 
be based on a number of different factors. For example, payments 
can be aggregated based on consumer, provider, payment method, 
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or a combination of any or all of these factors. This aggregation 
function can be performed entirely or in part within consumer 95 
electronic appliances, or it could be performed centrally by a 
centralized clearinghouse 200. 

Usage Clearinghouse 300 

Figure 33 shows an example usage clearinghouse 
Commerce Utility System 300. Usage clearinghouses services and 
functions, in general, may collect, analyze and "repurpose" 
detailed, summary, and/or derived usage information about the use 
and/or execution of digital properties and/or digital processes. 
This information may include any information descriptive of 
electronic transaction activity. Usage clearinghouses and/or 
support services may, for example, provide and/or facilitate the 
following: 

• Independent auditing and reporting (which may be 
presented independently of financial settlement 
clearing services); 

• General market researching; 

• Negotiating, implementing, determining, and 
communicating levels of privacy and confidentiality 
with customers and value chain participants regarding 
such usage information; and 

• Mass customized marketing and consolidated list 
selling, renting, or licensing. 
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In more detail, usage clearing services in accordance with 
the present inventions may provide, for example, any combination 
of the following detailed features and/or functions: 

• Compiling, aggregating, using, deriving and/or 
providing information descriptive of and/or otherwise 
relating to, use of a secure containers), secure 
container contents, and/or any other content and/or 
any digital control process(es), wherein such 
information describes and/or otherwise relates to (a) 
one or more users of content and/or processes, (b) one 
or more classes of content, control processes, uses of 
content, and/or users, and/or (c) one or more 
recipients of such usage information. 

• Enabling tracking and reporting of content and/or 
process control usage and/or processing information 
at a highly granular (e.g., detailed) level. 

• Can collect, aggregate, analyze, summarize, extract, 
report, distribute, rent, license, and/or sell usage 
information. 

• Employing information derived from user exposure to 
content, such as advertising, information materials, 
entertainment, training materials, business 
productivity software applications, etc., and securely 
supplying at least a portion of such derived 
information and/or related to such information, 
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through the use of VDE mechanisms in the preferred 
embodiment, to usage information aggregating and/or 
analyzing clearinghouses, and where such 
clearinghouse securely provides at least a portion of 
said usage information, or information derived from 
said information to at lest one further clearinghouse 
and/or value chain rightsholder; and wherein said 
clearinghouse may securely provide differing derived 
usage information to different other parties who have 
a clearinghouse role or other rightsholder role. 

Using the "information exhaust" audit trails created 
by, and/or derived from, user protected processing 
environment metering based on a variety of different 
techniques (for example those disclosed in Ginter, et 
a!.). 

Ability to collect and analyze detailed usage 
information such as the number of times a digital 
property or any portion of a property has been 
opened, extracted from, embedded into, or executed; 
or the length of time a value chain participant has 
used a property such as an interactive game or 
multimedia presentation, computer software, or 
modules or subparts of such products. 
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Providing a variety of repurposing capabilities for 
usage information arriving from consumers or other 
secure protected processing environments. 

Providing independent third party auditing 
capabilities useful, for example, for archiving and 
non-repudiation. 

Providing information based upon usage auditing, 
user profiling and/or market surveying related to use 
of one or more secure containers and/or content 
and/or VDE managed process control in the preferred 
embodiment 

Providing neutral, trusted third-party audit usage 
aggregating and reporting services for rights holders, 
consumers, and/or other value chain participants 
and/or interested parties such as governmental bodies 
(information for taxation, law enforcement, 
commercial surveying and statistics, etc.). 

Providing audit opportunities in conjunction with 
rules and controls rights and permissions clearing (for 
example, to provide a report about which rules and 
controls permissions and rights, were exercised, for 
example by whom, for what, and when - thereby 
tying actual user activity back to specific 
permissioning and rights and/or rules and controls 
templates). 
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In the preferred embodiment, providing standardized 
and custom reporting and analyzing based upon VDE 
rules and controls and produced and delivered in 
.VDE containers to each and/or any one or more 
grouping of content creators, content distributors, 
industry analysts, trade associations, and any other 
stakeholders and value chain participants, and/or any 
other interested parties such as government 
statisticians, regulators, and/or taxation authorities. 

Providing any combination of raw, refined, 
summarized, derived, and aggregated trusted data 
reporting for the support of plural business models 
within any value chain, and/or across and/or plural 
value chains. 

Distributing, to value chain participants and other 
parties within or outside of the electronic community, 
usage information separately from and/or with 
financial settlement clearing services. 

Supporting privacy and confidentiality controls fully 
protecting rights of all value chain participants 
interests related to usage information, including, for 
example, rights inherent in VDE chain of handling 
and control managed business models. 

Can accommodate privacy concerns, e.g., to not 
reveal more information than a consumer or value 
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chain content distributor, aggregator, repurposer, or 
other user of an electronic device that employs, in the 
preferred embodiment, VDE for secure, managed 
content or other process control, authorizes, and, for 
example, to inform such authorizing user of what 
kind of information is being gathered and/or cleared). 

Can be trusted to automatically, based at least in part 
upon rules and controls, conceal (e.g., encrypt), 
remove, and/or transform one or more portions of 
confidential or proprietary usage information before 
further processing of such information or delivering 
of such information to any one or more additional 
parties, including any further usage clearinghouse(s), 
thereby efficiently protecting privacy and 
confidentiality, including protecting business trade 
secret information. 

Protecting key business model information from 
prying eyes of other interested parties, and/or from 
inadvertent disclosure to other interested parties 
and/or to the public, thereby laying the foundation for 
truly trusted, commercial networks. 

Allowing value chain participants, including, for 
example, commercial publishers and distributors, 
and/or consumers and service and/or product provider 
organizations, to negotiate the level of detail of usage 



147 



information to be conveyed to any given value chain 
rightsholders, and wherein such level of detail may 
differ according to who the specific receiving parties 
are and the specific type and/or subtype of usage 
information, and where plural, differing levels of 
detail for differing portions of such usage information 
may be provided to a given usage information 
receiver and/or as a given deliverable, and where such 
determination of detail is, at least in part, determined 
by the rights of a given party at least in part described 
by VDE rules and controls information in the 
preferred embodiment. 

Allowing consumers and organizations to negotiate 
the level of detail of information conveyed to value 
chain rightsholders. 

Allowing consumers or other value chain participants 
- creators, publishers, distributors, repurposers — to 
specify and/or negotiate the level(s) of detail, 
aggregation and/or anonymity they desire with 
respect to usage information regarding their usage of 
any given piece of content, content class, specific 
.process, process class, and/or payment requirement 
(e.g., anonymity, and/or the maintenance of privacy 
related to some or all usage details, may require a 
payment premium to offset the loss of the value of 
such information). 

148 



Allowing information consumers and/or other value 
chain participants to customize their "information 
exhaust" and to set rules and controls for how they 
wish to have their usage information aggregated, or 
otherwise used - subject to the competing 
requirements of rightsholders to receive information 
they are entitled to and/or receive information that 
user and rightsholders mutually, electronically agree 
may be provided to rightsholders. Users and/or one 
or more rightsholders may have the right to specify 
limits upon (e.g., use VDE chain of handling and 
control), and/or describe specific usage information 
that may or must be to be delivered to, one or more 
other rightsholders. 

Supporting substantial value chain participant control 
over what kind of value chain participant usage 
information is accumulated, who can access which 
information and how such information may be used, 
how such information is gathered and processed, and 
the extent that usage records are tied to a specific 
value chain participant or organization. 

Securely using containers (e.g., using VDE secure 
containers in combination with VDE protected 
processing environment and communications security 
capabilities as described in Ginter, et al.) in any step, 

149 



part, and/or process of providing secure usage 
clearing services. 

Supporting providing discounts, subsidies and/or 
coupons to value chain participants, for example to 
consumers, distributors, repurposers, etc., in 
exchange for usage data or more finely grained usage 
data (for example, ameliorating privacy concerns in 
some contexts). 

Generating and supplying to interested parties 
marketing research and reporting and consolidated 
marketing lists (for targeted mailing, direct sales, and 
other forms of targeted marketing. Such materials are 
generally analogous to independent magazine and 
newspaper circulation audits, television audience 
ratings reports, and/or commercial targeted marketing 
lists, but generating in a highly efficient, distributed, 
and secure electronic environment. Such materials, 
when desired, can be provided with important new 
forms of detail (e.g., viewing, printing, extracting, 
reusing, electronically saving, redistributing, etc.), 
with far greater granularity of information, and with 
customized, selective reporting of materials based 
upon recipients requests, payments, rights, and/or 
conflicts of interest with one or more parties who 
have a rightsholder's interest in one or more portions 
of the underlying information. 
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Using detailed usage information to automatically 
generate classification hierarchies, schemes, groups, 
and/or classes, and automatically assigning 
individuals, groups of individuals, organizations, 
groups of organizations, digital and/or analog content 
or groups of digital and/or analog content to one or 
more classes derived from usage data created, 
collected, transmitted, in conjunction with at least one 
secure container and/or VDE in the preferred 
embodiment. 

Supporting advertising and marketing, including 
supporting efficient value chain automation of the 
delivery of such services, such as automatic targeting 
or delivery of advertising and/or other marketing 
materials to defined sets (e.g., one or more classes) of 
consumers, professionals, employees and companies, 
in which the sets may be defined by self-selection, 
usage data, usage data profiles, or by any other 
means, and wherein said sets may be comprised of 
any one or more value chain participants (e.g., 
creators, consumers, distributors, service providers, 
web sites, distributed clearinghouses) and wherein 
said one or more participants may receive differing, 
customized materials, and wherein said receiving 
participants may redistribute such materials, if 
authorized by rules and controls, and where such 
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participants may receive credit, coupons, monetary 
payment, and/or other forms of consideration for such 
redistribution, and where such redistribution may take 
the form of directing some or all of such received 
materials to one or more other parties at least in part 
based upon self-selection, usage data, usage data 
profiles, or by any other means, and wherein all such 
processes may be securely managed (e.g., supported) 
by internodal VDE chain of handling and control in 
the preferred embodiment. 

Determining payments and/or other consideration due 
to rights holders from advertisers based on value 
chain user exposure to advertising and at least in part," 
securely automating the distribution of portions of 
such consideration among plural parties having 
rightsholder interests related to the content and/or 
processes that served as a basis for determining such 
consideration. 

Supporting superior, targeted market segmentation 
and the design of more suitable information products 
and business models based on direct, more specific 
and detailed usage data and on customer and value 
chain preferences implied, explicit, and/or 
automatically derived from usage information, user 
profiles, class(s) identification information, etc. 
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Enabling "private" usage clearinghouses (a usage 
clearinghouse controlled and/or operated by an 
organization) to acquire certain detailed usage 
information and where such usage clearinghouses 
may perform usage analysis and/or other processing 
of such information and provide to more centralized 
and/or other party clearinghouses and/or other value 
chain participants, selectively limited usage 
information (e.g., employing higher level 
abstractions, summary information, restrictions on 
and/or manner of use of usage information — viewing, 
printing, saving, redistributing, etc.) for some or all of 
such usage information, and where differing 
limitations on such usage information may be applied 
to usage information derived from usage of differing 
classes of content, processes, users, and/or user 
groups, and where such limitation capabilities 
provide important additional protection of the 
confidential trade secret information of a company or 
other organization by concealing the detailed nature 
of certain internal activities, and where there may be a 
requirement by one or more other parties in a value 
chain for payment and/or other consideration in 
return for the retention of such detailed usage 
information. 
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Enabling organizations to employ private usage data 
clearinghouses on corporate Intranets, where such 
clearinghouses are integrated with organization 
document workflow and/or data warehousing 
systems. 

Receiving, with private usage organization (e.g., 
corporation, government agency, partnership, or any 
other organized operating entity) clearinghouses, 
usage data from electronic appliances within the 
organization, and aggregating records into detailed 
reports for internal use, and/or reporting raw, detailed 
data for internal use, but only aggregating usage data 
into summary reports for external distribution, for 
example, to rights holders and/or other value chain 
participants, and/or one or more commercial 
clearinghouses, and where detailed data for internal 
use is, in the preferred embodiment, protected as 
VDE protected content and access or other use of 
such content is limited to specified parties and/or in 
specified ways based, at least in part, on the specified 
parties securely maintained electronic identity, 
including, for example, any relevant party class 
identification information (e.g., member of a certain 
research group, senior executive officer) that has 
associated specific information usage privileges. 
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Identifying and supplying, through private usage 
clearinghouses, usage related information providing 
important value usage data for allocating internal 
organization resources, directing research, and other 
important business purposes. 

Distributing usage clearing (e.g., for efficiency and/or 
other reasons). 

Distributing usage clearing functions across a 
network or other system (for example, every 
consumer and/or other value chain participant node is 
potentially a distributed usage clearing service at least 
in part initiating its own, secure usage clearing, and 
where such participant node may communicate usage 
information directly to one or more other 
participants) and, in the preferred embodiment, in 
accordance with rules and controls and other VDE 
techniques as described in the Ginter, et al patent 
specification. 

Hierarchically organizing usage clearinghouses, at 
least in part to protect confidentiality at each level in 
the hierarchy. 

Granting authority and/or providing services to, or in 
conjunction with, one or more distributed usage sub- 
clearinghouses whose operations may be located 
logically and/or physically elsewhere, such as within 
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a company or government agency and/or within one 
or more jurisdictions and/or serving subsets of the 
overall business focus area of a senior usage 
clearinghouse. 

Distributing and/or otherwise authorizing usage 
clearing functions across a system or network, for 
example, where every consumer and/or certain or all 
other value chain participant protected processing 
environment (node) can potentially support a 
distributed usage clearing service, and function in the. 
context of the overall Distributed Commerce Utility. 

Initiating its own, secure usage clearing transactions 
directly with one or more other participants. 

Providing interoperable operation with one or more 
other participant interoperable nodes, using any or all 
activities employing Virtual Distribution 
Environment techniques. 

Use of clearinghouse to generate usage information 
used, at least in part, in the design and/or marketing 
of products and/or services related to the products 
and/or services whose usage is described by such 
usage information. 

May be organized hierarchically, peer-to-peer, or in a 
combined mode where responsibility for usage 
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clearing may be distributed in differing fashions for 
differing commerce models and/or activities and/or 
value chains, and where certain one or more parties 
may be, for example, hierarchically more senior to 
other parties in one or more instances, and 
hierarchically a peer or less senior in one or more 
other instances, that is, the relationship among 
participants is programmable and may be set (and 
later modified) to represent one or more desired usage 
clearing arrangements for given commerce activities, 
value chains, or models. 

Figure 33 shows an example usage clearinghouse 300 from 
a process point of view. Usage clearinghouse 300 in this example 
collects, analyzes and reports on the usage of digital information 
including, but not limited to, the usage of digital content. Usage 
clearinghouse 300 in this example performs the following 
functions: 

• Data collection 314, 

• Database management 316, 

• Privacy control 318, 

• Secure auditing 320, 

• Secure reporting 322, 

• Data aggregation 324, 

• Advertising and marketing 326, 

• Usage analysis 328, 

• Replication 330, and 
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• Propagation 332. 

Communication between usage clearinghouse 300 and other 
electronic appliances 100 may be by way of secure electronic 
containers 152, if desired. As explained in more detail in 
5 connection with financial clearinghouse 200, usage clearinghouse 
300 may receive the containers in real time and/or on an 
asynchronous receipt basis. In the usage clearinghouse 300, the 
real time requirement may involve advertising or ratings 
information that loses some or all of its value as a function of time 

1 0 (e.g., if certain ratings information isn't delivered by a particular 
time, it may no longer be relevant in a given market analysis; or if 
advertisers don't receive usage information promptly, they may 
not be able to respond to customer tastes as effectively). Another 
case may involve a required delivery of usage information (e.g., a 

1 5 user on vacation returns to find their required audit date and grace 
period has expired, and their use of certain properties is prohibited 
until the audit is performed). The asynchronous delivery case 
would still be preferable in some instances for the same reasons as 
above in connection with financial clearinghouse 200. 

20 Data collection function 3 14 is used to gather usage records 

302 in addition to other types of information, such as, rules and 
controls 1 88 (which may provide information concerning prices 
and permissions, for example), financial statements 240a, detailed 
financial reports 240b, and requests for usage information and/or 

25 analysis 336. Data collection function 3 14 may closely interact 
with database management function 316 - resulting in various 
types of information being stored and maintained in a usage or 
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other database. Replication and propagation functions 330, 332 
may be used to synchronize the contents of database 316 with 
other databases (for example, maintained by other usage 
clearinghouses 300) and/or to provide a distributed database 
5 across a number of secure network protected processing 
environments or electronic appliances. 

Data aggregation 324 and analysis 328 may be used to 
analyze the contents of data collected by data collection function 
3 1 4 and/or stored within database 3 1 6, enabling usage 

1 0 clearinghouse 300 to perform auditing 320 and/or reporting 322. 
Privacy control 3 1 8 may be used in conjunction with reporting 
function 322 to expose only certain information and not others to 
third parties — thereby protecting the privacy and confidentiality 
concerns of consumers for whom usage information has been 

1 5 collected. Such pending control 3 1 6 can be expressed in rules 
associated with the containers in which the information arrived. 

Reporting function 322 may generate a variety of usage 
auditing reports 304. In addition, usage clearinghouse 300 may be 
used to provide advertising and/or marketing support 326 (e.g., to 

20 help target advertising to demographically appropriate consumers 
and/or to provide market and advertising research). Thus, in one 
example, usage clearinghouse 300 may itself produce and/or 
distribute advertising 340 for viewing by certain targeted 
consumers or deliver such advertising on behalf of others. Usage 

25 clearinghouse 300 may also generate customized responses 342 in 
response to information requests 336, and can also generate 
release signals 344 authorizing electronic appliances 1 00 to delete 
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and/or make "no longer pending" the usage information from local 
databases once associated audit records have been transferred to 
usage clearinghouse 300 and that transfer has been confirmed. 
Consumer 95 may have an interest in keeping rather than deleting 
5 this usage information after it has been "released" (e.g., as a matter 
of curiosity, to monitor others' behavior (employees, children, 
etc.)) 

Usage clearinghouse 300 may generate its own controls 
1 88b to, for example, govern how usage information, market 

1 0 analysis information or other information can be used by others. 
For example, usage clearinghouse 300 might be prepare a 
proprietary report or analysis that it provides to third parties in 
return for compensation. Usage clearinghouse 300 may insist that 
the people that they provide the report to do not redistribute the 

1 5 report to anyone else. Usage clearinghouse 300 may enforce this 
requirement electronically by delivering the report within one or 
more electronic containers 152, and associating electronic controls 
1 88b with the report These electronic controls 1 88b could 
enforce the "no redistribute" prohibition along with other 

20 conditions grants and/or limitations (e.g., the report can't be 

modified, the report can be printed and viewed, the report may be 
excerpted, etc.). 

As mentioned above, usage clearinghouse 300 may also 
receive financial statements 240a and/or detailed financial records 

25 240b or other financial information — and may generate its own 
financial statements 240c and/or detailed financial records 240d. 
For example, the usage clearinghouse 300 might provide a service 
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to content providers in which the usage clearinghouse 300 
receives controls 1 88a from content providers similar to the 
controls delivered to consumers 95. Based on a comparison of 
these data, usage clearinghouse 300 might make estimates as to 
5 the amounts of money that the content providers should expect to 
receive from financial clearinghouses 200. Usage clearinghouse 
300 might thus provide an independent audit function — serving 
as a double check on financial clearinghouses 200 and providing a 
fraud detection function (e.g., people submitting usage records 
1 0 that don't have associated payments or otherwise incorrect 
payment amounts may be detected by the usage clearinghouse 
300). In addition, the control 188 might represent closed models 
that content providers are considering implementing, and usage 
clearinghouse 300 might then offer a service in which it runs a 
1 5 comparison against the usage data it actually collects to build a 
model of what the financial results might look like if the content 
provider actually instituted the proposed model. 

Figure 34 shows an example architecture of usage 
clearinghouse 300. In this example, usage clearinghouse 300 
20 includes a secure communications facility 346, a database and 
transaction processor 348, an authenticator 350, an authorization 
checker 352 and a data aggregator 354. Usage clearinghouse 300 
architecture may be based on the rights operating system 
architecture shown in Figures 12 and 13 of the Ginter et al. patent 
25 disclosure. 

Secure communications 346 provides communications with 
a variety of electronic appliances 100 over electronic network 1 50 
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via secure containers 152 in this example. Database and 
transaction processor 348 in this example performs most of the 
Figure 33 functions. An authenticates 350 may be used to 
authenticate consumers and/or data, an authorization checker 352 
5 may be used to check authorizations, and a data aggregator 354 
may be used to perform the data aggregation function 324. 
Authenticator 350 and authorization checker 352 perform 
authentication functions as described in the Ginter et al. disclosure 
in connection with secure electronic appliances and protected 

10 processing environments. 

Figure 35 shows an example overall usage clearing process. 
In this example, a provider 1 64 provides a digital property to 
consumers 95(1), 95(2), 95(3). For example, provider 1 64 might 
provide a novel or other work 166 to each of the consumers 95 

1 5 within electronic containers 152. One or more control sets 1 88 
may be associated with the work 1 66 (and may, in one example, 
be delivered within the same electronic container 1 52 used to 
deliver the work 166). The controls 188 may specify that certain 
types of usage information must be gathered in the form of an 

20 audit trail, and that the audit trail must be reported based on 
certain time and/or other events. 

Because container 152 can only be opened within a secure 
protected processing environment 154 that is part of the virtual 
distribution environment described in the above-referenced Ginter 

25 et al. patent disclosure, provider 1 64 can be confident that the 
required audit trails will be generated and reported as he or she 
instructs. As consumers 95 use the property 166, their electronic 
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appliances 100 automatically gather and store the usage 
information in the form of audit trails 302. Then, upon the 
occurrence of a specified event (e.g., once a month, once a week, 
after a certain number of uses, etc.), the consumer electronic 
5 appliances 1 00 send audit trail information 302 within digital 
containers to usage clearinghouse 300. 

Usage clearinghouse 300 collects the audit trail information 
302, may store it in its database 3 1 6, and analyzes the audit trail 
information to generate a report 304 which it may send to provider 
164 within a further electronic container 152. 

Provider 164 automatically receives secure information 
auditing the amount his or her work has been used and how it has 
been used, with usage clearinghouse 300 relieving the provider 
from having to collect or analyze this detailed usage information. 
In addition, usage clearinghouse 300 may serve to protect the 
privacy of consumers 95 by revealing only summary details 
authorized by them (for example, how many consumers have used 
the work 1 66 but not their names or addresses). This 
confidentiality function would be more difficult or problematic if 
provider 164 attempted to analyzed detailed usage records himself 
or herself. 

Figure 36 shows a more detailed example usage clearing 
process involving two different usage clearinghouses 300(1), 
300(2). In this example, a provider 164 delivers a work 166 
directly to consumers 95, and also to distributors 168 that may 
redistribute the work to the consumers. The controls 1 88 
associated with the distributed content 166 may specify that usage 
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clearinghouse 300(1) is to collect and analyze information relating 
to the usage of the content 166 directly distributed by creator 164, 
and that another usage clearinghouse 300(2) is to collect and 
analyze usage information pertaining to the usage of the work 1 66 
as distributed by distributor 168. Alternatively, usage 
clearinghouses 300(1), 300(2) may gather different types of usage 
information pertaining to the same electronic property 1 66 (for 
example, one usage clearinghouse might gather information 
pertaining to "pay per view" usage, whereas the other usage 
clearinghouse might gather usage information for all one-time 
purchases). Usage clearinghouses 300(1), 300(2) may each issue 
reports 304 to creator 164 and/or distributor 168 and/or consumer 
95. 

Figure 37 shows how a usage clearinghouse 300 can be 
used in combination with a financial clearinghouse 200. In this 
example, a consumer's electronic appliance 1 00 may send: 

• to usage clearinghouse 300, audit trail information 
302 pertaining to usage of electronic content, and 

• to financial clearinghouse 200, usage and payment 
audit trial information 228 pertaining to financial 
clearing activities. 

If desired, usage clearinghouse 300 and financial 
clearinghouse 200 may be operated by the same business (in this 
case, both usage and financial audit trail information could be sent 
within the same electronic container 1 52). The usage clearing 
functions performed by usage clearinghouse 300 may operate in 
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parallel with the financial clearing functions performed by 
financial clearinghouse 200 to support both detailed usage 
reporting and efficient financial clearing. 

Figure 38 shows another example usage clearing operation 
5 based on media and/or advertising content placement. Consumers 
95(1), 95(2), 95(N) may subscribe to various information 

distribution services 170A, 170B, These information 

distribution services 1 70 may distribute program material and 
advertisements (commercial content) produced by content 
10 providers 164. Consumers 95 consume the distributed content, 
and their electronic appliances 100 gather and report associated 

usage data to usage clearinghouses 300(1), 300(2) 

The usage clearinghouses 300 may perform demographic 
analysis on the received usage data and, based on this 
1 5 demographic analysis, target particular ads for other commercial 
content 164 to particular information services 170. For example, 
information service 170A might distribute program material and 
commercial content 164 of interest to runners and others with 
physical fitness interests. Usage clearinghouse 300(1) might 
20 analyze the usage data provided by the consumers 95 who 
subscribe to and view this type of information. Usage 
clearinghouse 300(1) is thus in a unique position to place ads in 
other commercial and non-commercial content that might be of 
interest to the same interest group. Similarly, information service 
25 1 70B might specialize in broadcasting information of interest to 
car enthusiasts. Usage clearinghouse 300(2) may gather usage 
data about the usage of this type of information — and is thus in a 
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unique and well placed position to distribute and target 
advertisements, commercial and non-commercial content to this 
group of consumers. 

Figure 39 shows an additional example usage clearing 

5 operation that may be performed by usage clearinghouse 300. In 
this example, usage clearing house 300 may be authorized by 
rights holders 164 to offer discounts based on the amount of usage 
information a consumer 95 is willing to disclose. This can, for 
example, be done with controls 188 for the property by selecting 

10 from among control sets and/or entering into an electronic 

negotiation (see Ginter et al. Fig. 76A and B). A rights holder 
might premeditate this as a general rule for their property — or 
given rights and permissions clearinghouses 400 could be 
authorized to deliver these control sets (e.g. based on their special 

1 5 position as collectors of particular categories of usage 
information). 

As one example, the consumer's electronic appliance might 
be a personal computer, and rights holders 164 who distribute 
computer software may be interested in knowing what software 
20 programs consumer 95 is using in addition to the ones they 

themselves are distributing. Consumer 95, on the other hand, may 
not want to reveal this detailed information about all of the 
software programs that are present on his or her personal 
computer. 

25 As another example, digital broadcast rights holders 1 64 

may want to know about every broadcasted program that 
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consumer 95 watches, whereas the consumer may not want anyone 
else to know the kinds of programs he or she is interested in. 

Usage clearinghouse 300 can effectively accommodate 
these countervailing interests by offering consumer 95 a financial 
5 incentive for more full disclosure but giving the consumer a 
choice. 

In this example, rights holder 164 distributes electronic 
content and associated controls to consumer 95. The controls may 
specify options for revealing usage information. The consumer 
10 may choose: 

• to pay full price and keep all usage information other than 
that essential for insuring payment absolutely secret; 

• to allow limited usage disclosure in return for a small 
discount on price; or 

15 • to take advantage of a big discount in return for allowing 

full disclosure of usage information. 
Some secretive consumers may want the outside world to 
know as little as possible about their usage habits and will be 
willing to pay full price to protect their privacy. Other consumers 
20 may not care what the outside world knows about their usage 
habits, and will want to take advantage of large discounts based 
upon more full disclosure. Any number of such option levels may 
be provided, allowing the consumer to, for example, select 
precisely what kinds of information are revealed and which ones 
25 are kept secret Because usage data is being collected within a 
secure protected processing environment 154 that is part of the 
consumer's electronic appliance 100, the consumer can be 
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confident that the usage data will be securely handled and that 
unauthorized disclosure will not occur without his or her consent. 

Based, for example, on one or more control sets 1 88 
provided to the consumers' protected processing environment 1 54 
and/or the consumer's selection made possible through such 
control sets, the consumer's protected processing environment 154 
could reveal no (or minimal) usage information, limited usage 
information or full usage information, to usage clearinghouse 300. 
Usage clearinghouse 300 can then freely analyze the limited and 
full usage information it collects, providing reports and analysis to 
rights holders 164 and to other third parties such as market 
researchers, brokers, advertisers, auditors, scientists and others. 

Rights and Permissions Clearinghouse 

Figure 40 shows an example of a rights and permissions 
clearinghouse Commerce Utility System 400. Rights and 
Permissions clearinghouse services may perform any combination 
of the following overall functions: 

• Registering digital objects and associated 
permissions, prices and/or other permitted and/or 
required operations supporting the execution of 
consequences for performing and/or failing to 
perform such operations; 

• Providing pre-approved permissions on demand in 
accordance with specified circumstances and/or other 
requirements such as class(s) of permission requester, 
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fulfillment, or ability to fulfill, payment requirements, 
etc.; 

• Securely and efficiently performing electronic 
copyright registration with the appropriate agency for 
one or more countries and/or other jurisdictional 
units; and 

• Reporting functions. 

In more detail, rights and permissions support services in 
accordance with these inventions that may include, for example, 
some or all of the following functions and features: 

• Identifying, distributing and verifying specific 
property rights and/or other business rules and 
controls along a digital electronic value chain. 

• Providing object registry services and rights, prices 
and/or other control information for registered 
objects. 

• Assigning to each digital object at least one 
identifying number and/or name in accordance with 
its own numbering and/or naming scheme and/or in 
accordance with one or more numbering and/or 
naming schemes defined by one or more other 
organizations, associations (e.g., standards 
consortiums), companies, and/or agencies (e.g., 
governmental regulatory bodies). 
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Receiving authority from secure chain of handling 
and control embodied in electronic control sets. 



Securely providing permissions (e.g., rules and 
controls based descriptions of permitted operations 
and associated consequences such as prices) for 
digital properties that have been registered and 
supporting automated association of such registered 
properties with rules and controls sets (e.g., updating 
of rules and controls, employing preset templates 
based upon classes of properties, etc.), that may be 
provided, for example, at least in part remotely and 
securely downloaded to the registering site during, or 
as a result of, such registration. 

Allowing rights holders in digital content to 
determine and flexibly define and securely provide to 
one or more rights and permissions clearinghouse 
ways in which they want their intellectual property 
products (for example, VDE protected digital 
properties) to be used and not used, and any 
consequences of such use and/or misuse. 

Providing VDE supported capabilities to distribute 
and manage rights and business rules (including pre- 
approved and other permissions) along an ad hoc 
electronic value chain, where such rights and business 
rules are persistently supported. 
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Providing digital object permissions on demand to 
people authorized to use a digital object. 

Can provide different terms based on different 
permissions securely associated with one or more 
combinations of classes of users (e.g., different age 
groups, jurisdictions, business capabilities, 
consumers, creators, providers, partners, government, 
non-profit organizations, educational organizations, 
organization membership, etc.). 

Providing rights holders with assurances that the 
terms they set are being adhered to by a potentially 
diverse and distributed value chain participant base. 

Can provide controls that do not include all possible 
permissions and/or distribute further, required and/or 
desired permissions upon request on an ad hoc and/or 
pre-planned basis according to the requester's rights 
(class and/or individual), for example, allowing rights 
holders to elect to distribute only the most frequently 
used permissions associated with a particular digital 
property, and allowing appropriate parties to obtain 
new permissions in accordance with the rights 
holder's model. 

Refreshing expired permissions upon request and/or 
upon an automated recognition of the expiration of 
such rights through the use of clearinghouse database 
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mechanisms and the automated provisioning and/or 
messaging to provide such permissions and/or notify, 
in the preferred embodiment, a VDE value chain 
participant of the need to acquire such permissions 
(notify such user, for example, before the user is 
actively attempting to use associated information 
and/or electronic control processes and thereby 
avoiding user frustration and inefficiency). 

Using secure containers such as those described in 
Ginter, et al., in any step, part, or process of providing 
secure rights clearing services. 

Creating, storing, distributions, and receiving rights 
and permissions "templates" allowing rights holders 
to efficiently and adequately specify rights, 
conditions and consequences, (e.g., compensation) to 
be associated with operations related to the use of 
their digital properties (and/or the use of VDE 
process controlled electronic events). 

Templates can directly correspond to digital control 
sets associated with properties, content users, user 
classes, and/or other digital information and/or 
physical or virtual sites and/or process control for 
event and event consequence governance. 

Templates can be self-executing. 
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• Templates can apply to multiple objects/instances. 

• Templates can be delivered independently of any 
digital objects they may be associated with. 

• Templates are extensible to anticipate new operations 
and scenarios, including, but not limited to new 
payment methods, pricing models and pricing levels, 
and new permissions. 

• Templates can flexibly recognize all kinds of digital 
rights including, for example, distribution and 
transmission and/or retransmission rights. 

• Templates can flexibly recognize individual identity 
and/or class identity rights. 

• Different templates can apply to different content 
and/or process control arrangement property types. 

• Plural templates can apply to the same property 
and/or process control arrangement. 

Rights and permissions clearinghouse(s) may maintain 
superset templates, permitting value chain participants 
arid/or hierarchically sub-clearinghouses to modify one 
or more of such superset templates to create templates 
employing a subset and/or extended set of said one or 
more superset templates. 
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Templates can oe compieieu in a uuatuci ui uuiuun 
ways using, for example, a graphical user interface 
and/or a rights management language. 
Template "applications" can be created and/or modified 
through the use of topographical, schematic, directly 
editable graphical representation of value chain rules and 
controls, where such rules and controls and value chain 
relationships are represented through the display of, for 
example, mixed iconic, positional, flow diagram, and 
textual information, and wherein rules and controls are 
implemented, for example, through the use of a rights 
management language, and wherein, for example, 
elements or higher level representation of such elements 
of the rights language may directly correspond to 
graphical representation components. 
Multiple value chain participants can contribute to 
and/or modify templates and/or contribute and/or modify 
different templates applying to the same digital 
information. 

Users can select between differing templates applying to 
the same digital information, including, for example, 
digital information describing and/or governing control 
processes (e.g., event management information) 
managed through, for example, secure VDE chain of 
handling and control. 

Distributing rights clearing functions across a network or 
other system (for example, every consumer and/or other 
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value chain participant node is potentially a distributed 
rights clearing service at least in part initiating its own, 
secure rights clearing, and wherein said participant node 
may communicate rights information directly to one or 
more other participant, interoperable clearing nodes, in 
the preferred embodiment, all activities employ VDE 
techniques as appropriate and as described in the Ginter, 
et al. patent specification). 
• Granting authority and/or providing services to, or in 
conjunction with, one or more distributed rights sub- 
clearinghouses whose operations may be located 
logically and/or physically elsewhere, such as within a 
company or government agency and/or within one or 
more jurisdictions and/or serving subsets of the overall 
business focus area of a senior rights clearinghouse 
distributing and/or otherwise authorizing rights clearing 
functions across a system or network, for example, 
where every consumer and/or certain or all other value 
chain participant nodes can potentially support a 
distributed usage clearing service initiating its own, 
secure rights clearing transactions and function in the 
context of the overall clearinghouse network, including, 
clearinghouse interoperation with one or more other 
participants interoperable nodes, and as elsewhere in this 
list, all activities employing, for example, VDE 
techniques as appropriate. 
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• One or more rights may be automatically provided to a 
participant based at least in part upon some aspect of 
content and/or process control usage, and such provided 
one or more rights may be supplied, for example, as a 
promotional component providing coupons in 
compensation for certain usage (e.g., purchasing) profile 
which may be directly ascertained from usage 
information or may be derived from a weighted formula 
involving a variety of variables. 

• May be organized hierarchically, peer-to-peer, or in a 
combined mode where responsibility for rights clearing 
may be distributed in differing fashions for differing 
commerce models and/or activities and/or value chains 
and where certain one or more parties may be, for 
example, hierarchically more senior to other parties in 
one or more instances and hierarchically a peer or less 
senior in one or more other instances, that is the 
relationship among participants is programmable and 
may be set (and later modified) to represent one or more 
desired rights clearing arrangements for given commerce 
activities, value chains, or models. 

Figure 40 shows an example rights and permissions 
clearinghouse 400 from a functional viewpoint. In this example, 
rights and permissions clearinghouse 400 may perform some or all 
of the following four main functions: 
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• Object registration. Rights and permissions 

clearinghouse 400 registers digital properties and 
their associated permissions and prices. 

• Permissions on demand. In response to queries, rights 

and permissions clearinghouse 400 provides 
permissions 1 88 together with associated prices in 
secure electronic containers 1 52. The permissions 
controls 188 may be provided independently of the 
content. 

• Negotiated permissions. In response to queries and 

requests, the rights and permissions clearinghouse 
400 negotiates permissions and/or prices on behalf of 
rightsholders who have delegated this responsibility 
to the rights and permissions clearinghouse. The 
rights and permissions clearinghouse 400 may also be 
an intermediary in the negotiations between 
rightsholders and rights users. Rightsholders and 
rights users may negotiate among themselves and 
report the results of those negotiations to the rights 
and permissions clearinghouse. 

• Reporting. Rights and permissions clearinghouse 400 can 

. provide reports to augment reporting performed by 
financial clearinghouses 200 and/or usage 
clearinghouses 300. 
In this example, rights and permissions clearinghouse 400 
may provide some or all of the following functions: 



177 



WO 98/10381 riT/USMU4262 

• Permission creating, updating or changing 408, 

• Permission distribution 410, 

• Database management 412, 

• Template definitions and/or management 414, 
5 • Negotiating permissions 416, 

• Reporting 417, 

• Replication 418, 

• Registration 419, and 

• Propagation 420. 

1 0 The rights and permissions clearinghouse 400's primary task 

of object registration is performed by database management 412. 
In this connection, rights and permissions clearinghouse 400 may 
receive control sets 1 88 and corresponding object identifications 
422 within the same or different electronic containers 152, and 

1 5 then "register" this information in a database 4 1 2 for later 

reference. Rights and permissions clearinghouse 400 may assist 
rights holders in defining control sets 188 specifying rights and 
permissions relating to the rights holder's electronic properties by 
providing a template function 414. Registration process 419 and 

20 database 412 may register control sets 188 in addition to objects or 
properties 166. 

Rights and permissions clearinghouse 400 database function 
412 and distribution function 410 may be used to distribute 
permissions on demand in response to requests 402, and may also 
25 be responsible for the task of distributing (via distribution function 
41 0) all permissions relating to a particular property. Since 
permissions and/or prices may expire or change, rights and 
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permissions clearinghouse 400 can also be responsible for 
updating control sets 188 specifying previously issued 
permissions and/or prices and distributing those updated control 
sets. 

5 Rights and permissions clearinghouse 400 may also provide 

a reporting function 417, issuing reports 406 pertaining to the 
permissions and/or prices it has issued or distributed, for example. 
In this example, the operation of rights and permissions 
clearinghouse 400 provides audit opportunities, i.e., a channel 
1 0 through which to attach usage information. Such audit operations 
(which may, for example, be provided by integrating rights and 
permissions clearinghouse 400 functions with usage clearinghouse 
300 functions) could be used to create integrated reports about 
which permissions were provided and which permissions were 
1 5 exercised - very valuable information for market research and 
business consequences as well as providing additional 
accountability to rightsholders. 

This rights and permissions clearinghouse 400 audit 
function can be especially beneficial to preserve confidentiality. 
20 For example, a private rights and permissions clearinghouse 400 
may be extended to provide payment aggregation in order to hide 
confidential individual transaction level information from the 
financial clearinghouse 200. In another example, a rights and 
permissions clearinghouse 400 can issue reports 426 indicating, 
25 for example, the number of registered objects in database 4 1 2 at 
the beginning of a reporting period, the number of new objects 
registered, and some aggregate statistics concerning perhaps the 
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numbers of kinds of permissions associated with these objects 
and/or average or median prices for certain kinds of objects. 

Rights and permissions clearinghouse 400 can also respond 
to queries 402 with responses 428. A request, for example, may 
5 consist of a request for permissions — which may be 

automatically granted; or the request may need to be qualified by 
the rights and permission clearinghouse 400 to determine whether 
the requester is qualified to receive the permissions. 
Qualifications might be established by presentation of one or more 

10 valid certificates, which might be simply checked, or stored in the 
database 412 for transmission to providers along with other 
information about permissions granted by the clearinghouse. In 
the preferred embodiment, other qualifications might be based on 
a shared secret (e.g., one or more tags from a control set 1 88 held 

15 by the requester) known by the requester's PPE 54 and the rights 
and permissions clearinghouse 400. This shared secret might be 
used in combination with a certificate, or in cases when 
qualification requirements are lower or have already been 
established (e.g., to have received the shared secret in the first 

20 place), the shared secret alone might be adequate to receive, for 
example, a permission that replaces or updates an expired 
permission. 

Rights and permissions clearinghouse 400 also includes a 
permission negotiation engine 416 that may be used to negotiate 
25 permissions 1 88 that haven't been pre-approved by the rights 
holder. For example, suppose that a consumer 95 wants to 
exercise a right that is not within database 412. The consumer 95 
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could request the right. In response, rights and permissions 
clearinghouse 400 could determine whether the rights holder has 
authorized it to negotiate for the right on behalf of the rights 
holder. If the rights holder has not given the rights and 
5 permissions clearinghouse 400 the power to negotiate, the 
clearinghouse could contact the rights holder and request 
authorization and/or the permission itself. If the rights holder has 
granted the rights and permission clearinghouse 400 negotiating 
authority, the clearinghouse could enter into an electronic 
1 0 negotiation (see Ginter et al. Figures 75A-76B) between the 
consumer's control set and the rights holder's control set. The 
resulting negotiated control set could be sent to the consumer, 
allowing the consumer to exercise the right. 

Figure 41 shows an example architecture for rights and 
1 5 permissions clearinghouse 400. In this example, rights and 

permissions clearinghouse 400 includes a secure communications 
facility 430, a database and transaction processor 432, an 
authenticator 434, an authorization checker 436, and a registration 
processor 438. As discussed above, the rights and permissions 
20 clearinghouse 400 architecture may be based on the rights 

operating system architecture shown in Figures 12 and 13 of the 
Ginter et al. patent disclosure and described in associated text. 

Database and transaction processor 432 performs most of 
the functions shown in Figure 40. Registration processor 438 may 
25 perform the registration function 419. Secure communications 
facility 430 communicates securely over electronic network 150 
with consumers 95, authors 164, publishers 168, aggregators 170, 
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repackagers 174, and other value chain participants via secure 
containers 152. Authenticates 434 and authorization checker 436 
perform authentication functions as the Ginter et al. patent 
disclosure describes in connection with secure electronic 
5 appliances and protected processing environments. 

Figure 42 shows an example rights and permissions clearing 
process. In this example, author 1 64 sends a work 1 66 with a 
control set 188A including controls A to a publisher 168. 
Publisher 168 — in accordance with a secure chain of handling and 

1 0 control — adds controls B to the control set to form a new control 
set 188AB. Publisher 168 publishes the work 166 with control set 
188AB to consumers 95. Publisher 168 may also specify a less 
often used, but sometimes necessary additional set of permissions 
C within a more comprehensive control set 1 88ABC (for example, 

1 5 controls C may allow journalists to excerpt certain parts of work 
1 66 for specific purposes). 

Publisher 168 may register control set 188 ABC (and, if 
desired, also control set 1 88AB and control set 1 88A) with rights 
and permissions clearinghouse 400. The publisher 1 68 may also 

20 include additional "controls over controls," or "permissions for 
permissions" "D" (e.g., distribution controls described in 
connection, with Figures 79-85 of the Ginter et al. patent 
disclosure) along with controls 188ABC. These additional "D" 
controls may specify the circumstances under which rights A, B 

25 and/or C may be granted (qualification of credentials, frequency of 
reissue, number of controls for a given user, etc.). 
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Consumer 95 (or any other provider, such as an aggregator, 
repackages author, or another publisher) may request a copy of 
any of these various control sets registered with rights and 
permissions clearinghouse 400. For example, if the consumer 95 
5 is a journalist who uses the work 166 in accordance with control 
set 1 88 AB and decides she wants to excerpt the work for certain 
purposes, she may request the control super set 188ABC that 
publisher 168 previously registered with rights and permissions 
clearinghouse 400. As another example, a consumer 95 in 

1 0 Germany may have received the control set 1 88 intended for U.S. 
distribution, and may need to request a different control set 
accommodating the European legal and monetary environment. 
Additionally, a rightsholder may modify previously distributed 
controls at a later date to add new rights, provide a "sale," take 

1 5 away rights, etc. - with rights and permissions clearinghouse 400 
being responsible for distributing these new control sets either on 
demand. 

Figure 42A shows another example in which consumer 95 
may register with the rights and permissions clearinghouse 400 a 

20 control set 188X that pertains to an object such as a file or 
software program already received by consumer 95. This new 
control set 188X requests the rights and permissions clearinghouse 
400 to send to consumer 95 a new control set 1 88Y for the named 
object whenever the controls registered for that object at the rights 

25 and permissions clearinghouse 400 are modified. The rights and 
permissions clearinghouse 400 may automatically send updated 
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control set 188Y to all registered users of a particular digital 
property. 

In a different example, publisher 168 might distribute work 
1 66 with a very limited control set 1 88X allowing the consumer 
5 95 to view only the abstract and specifying rights and permissions 
clearinghouse 400 as a contact point for obtaining permission to 
view or otherwise use the content as a whole. Consumer 95 could 
then contact rights and permissions clearinghouse 400 to obtain a 
more expansive control set 188Y allowing additional levels of 

10 usage. This provides a high degree of accountability and 

expanding auditing capabilities, since it requires consumers 95 to 
contact rights and permissions clearinghouse 400 in order to 
actually use a previously distributed property. Similarly, rights 
and permissions clearinghouse 400 may provide updated control 

15 sets 188Y to replace expired ones. This mechanism could be used, 
for example, to provide a variable discount on a particular item 
over time (for example, to allow a movie distributor to discount its 
first run film six months after its initial release date without 
having to decide at time of initial release how much the discount 

20 will be). 

Figure 43 shows a further example rights and permissions 
clearing operation performed by rights and permissions 
clearinghouse 400. In this Figure 43 example, each of authors 
164, publishers 168, aggregators 170, and optionally other 
25 additional value chain participants, register their own control sets 
188A, 188B, 188C, respectively, with a rights and permissions 
clearinghouse 400 — potentially also registering additional 
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controls controlling distribution of their provider controls. Rights 
and permissions clearinghouse 400 may then distribute a new, 
combined control set 188ABC consistent with each of the 
individual control sets 188 A, 188B, 188C - relieving any of the 
5 value chain participants from having to formulate any control sets 
other than the one they are particularly concerned about. In this 
example, rights and permissions clearinghouse 400 may also have 
an interface to other organizations (e.g., with a government agency 
440, such as a Copyright Office — or with another type of 

1 0 organization such as professional associations). Rights and 
permissions clearinghouse 400 may automatically register 
copyright in works and other objects registered with the rights and 
permissions clearinghouse 400 — reducing or eliminating such 
burdens from having to be performed by the rights holders 

1 5 themselves. The copyright registration interaction between the 
rights and permissions clearinghouse 400 and the government 
agency 440 may, for example, make use of VDE and secure 
containers 152. 

Figures 44A-44E show an additional rights and permissions 

20 clearing process that may be performed using rights and 

permissions clearinghouse 400. In this example, a publisher 168 
may provide, a property 166 and associated control set 188a to a 
consumer 95 (see Figure 44A). The consumer may use her 
electronic appliance 100 and associated protected processing 

25 environment 1 54 to attempt to access the property 1 66 using 

control set 1 88a, but may determine that she requires an additional 
control set 1 88b in order to access the property the way she 
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wishes. The consumer's electronic appliance 100 may generate a 
request 402 to a rights and permissions clearinghouse 400 (see 
Figure 44B). In response, the rights and permissions 
clearinghouse 400 may distribute the requested control 188b 

5 containing the permissions and pricing information requested by 
the consumer 95 (see Figure 44C). The consumer may then use 
the property 166 in accordance with the control set 188 and 
generate usage/audit trail information 302 based on the 
consumer's usage (see Figure 44D). The consumer's electronic 

10 appliance 100 may report this usage information to usage 

clearinghouse 300, and may delete and/or release as "pending" the 
internally stored usage information once it receives a release 
signal from the appropriate clearinghouse (see Figure 44E). 



IS Rights Templates 

Figures 45A and 45B show example rights templates 450, 
and Figure 45C shows an example corresponding control set 188. 
Rights template 450 may be analogous in some respects to "fill in 
the blank" forms. Rights holders can use rights templates 450 to 

20 efficiently and effectively define the rights associated with a 
particular digital property. Such templates 450 are useful in 
framing the general purpose capabilities of the virtual distribution 
environment technology described in the Ginter et al. patent 
disclosure in terms that are sensible for a particular content 

25 industry, provider, content type or the like. This allows a user 
such as a provider to be presented with a focused menu of 
resources that be applicable or useful for a particular purpose. 
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For example, templates 450 may make some assumptions 
about the character of the content or other information being 
controlled, how it is partitioned or otherwise organized and/or the 
attributes those organizational entities have. Templates 450 
5 simplify the process of defining permissions, and reduce or 
eliminate the need for specialized knowledge and substantial 
investments of time to exploit the underlying capabilities of the 
virtual distribution environment. It may be possible in this 
example for a user to avoid using templates 450 altogether and 

1 0 instead define permissions 1 88 in terms of a rights management 
language (for example, a natural or computer-based language) — 
but a large percentage of users will prefer the easy-to-use graphics 
interface that templates 450 may provide — and won't mind 
giving up the additional flexibility and associated complexities 

15 when undertaking the day-to-day business of defining permissions 
for a large number of different pieces of content. 

Example rights template 450 shown in Figure 45 A (which 
may be appropriate for text and/or graphics providers for example) 
defines a number of different types of usage/actions relevant to a 

20 particular digital property, such as, for example, "view title," 
"view abstract," "modify title," "redistribute," "backup," "view 
content," and "print content." Rights template 450 may further 
provide a "menu" or list of options corresponding to each type of 
usage. These various options allow the rights holder to define 

25 rights that others may exercise in connection with the property. 
For example, the rights may comprise: 
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• Unconditional permission, 

• Permission conditional on payment, 

• Permission based on content, 

• Unconditional prohibition, and 

• Prohibitions and/or permissions based on other factors. 
Rights holders may "fill in" or select between these various 

options to defme a "rights profile" corresponding to their 
particular property. In this example, rights template 450 may 
further models and/or levels for rights to be exercised conditional 
on payment. Such pricing models and levels may flexibly define a 
variety of different sorts of business pricing, such as, for example, 
one time charges, pay per view, declining cost, etc. See Figure 
45B for an example of how pricing models and levels might be 
specified using a graphical interface. 

Rights template 450 in this example can be self executing 
and/or can be "translated" or compiled automatically into one or 
more control sets 1 88 providing the necessary controls for 
implementing the rights holder's selections. Figure 45 B, for 
example, has a "view title" control 188a that allows unconditional 
viewing of the title as specified by the Figure 45 A rights template 
450. Similarly, the Figure 45B example controls 188 includes 
further control set elements 188(2) . . . 188(N) corresponding to 
other rights and permissions 188 the rights holder has defined 
based upon the Figure 45 A rights template 450. 

In this example, rights template 450 can be extensible. For 
example, as new technology enables and/or creates new 
operations, rights template 450 can be extended to accommodate 
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the new operations while still being "upward compatible" with 
preexisting rights templates. Different rights templates 450 can be 
used for different types of properties, different value chain 
participants, etc. — and at the same time, certain rights templates 
5 might apply to multiple objects or properties, multiple value chain 
participants, etc. Some rights templates 450 can be supersets of 
other rights templates. For example, an overall rights permissions 
template 450 could define all of the possible rights that might 
apply to a particular property or class of properties, and sub- 

1 0 templates could be further defined to define rights associated with 
different consumers, classes of consumers, or rights holders, 
Thus, for example, an author might use a sub-template that is 
different from the one used by a distributor. Templates can also 
be recursive, i.e., they can be used to refer to other templates (and 

1 5 similarly, the control sets they define can refer to other control 
sets). 

Rights and permissions clearinghouse 400 might partially 
fill in rights template 450 — or an automatic process could be used 
(based, for example, on rights holder's pre-existing instructions) 

20 for completing and/or duplicating rights templates. Rights holders 
could use a graphical user interface to complete rights template 
450 (e.g., by displaying a list of options on a computer screen and 
pointing and clicking with a mouse pointing device to fill in the 
options desired). In another example, a rights holder could define 

25 his or her preferences using a rights management language that a 
computer could automatically compile or otherwise process to fill 
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in rights template 4S0 and/or construct associated control set(s) 
188. 

Figure 46 shows an example rights and permissions clearing 
process using rights template 450. In this example, rights and 
5 permissions clearinghouse 400 and/or individual rights holders 
define rights template 450 (Figure 46, block 452( 1 )). The rights 
are then filled in the rights template 450 to define permissions 
granted and withheld, and associated pricing models and levels 
(block 452(2)). The rights holder associates the permissions 

1 0 defined by the rights template with the object (e.g., by creating 
one or more control sets 1 88 that reference and/or apply to the 
property being controlled) (block 452(3)). The rights holder may - 
then convey the permissions (control set 1 88) with or separately L 
from the object (block 452(4)). Rights holders may send these 

15 control sets 188 directly to consumers 95 (block 452(5)), and/or - 
they may sent them to a rights and permissions clearinghouse 400 
for registration and storage in a database (block 452(6)). Rights 
and permissions clearinghouse 400 may provide such 
preauthorized permissions to consumers (block 452(7)) on 

20 demand upon receiving consumer requests (block 452(8)). 

As described above, providers may control distribution of 
such pre-authorized permissions by rights and permission 
clearinghouse 400 by the mechanism of providing additional, 
"distribution controls" directing and/or controlling the distribution 

25 process. 
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Certifying Authority 

Figure 47 shows an example certifying authority Commerce 
Utility System 500. Certifying authorities and services may, in 
general, create digital documents that "certify," warrant, and/or 
5 attest to some fact. Facts include, for example, identification 
and/or membership in a particular class, e.g., such as an 
organization; age group, possession of a certain credential type; 
being subject to one or more certain jurisdictions; and/or having a 
certified one or more rights to use content and/or processes for a 
1 0 fixed time period or terminating at a specific time. 

In more detail, a certifying authority in accordance with these 
inventions may provide any combination of the following 
advantageous features and functions, for example in the form of 
certificates: 

15 • Electronically certifying information used with or 

required by rules and/or controls such as 
authenticating, identity, class membership and/or 
other attributes of identity and/or context, and 
including automatically certifying said information 

20 based upon the source (for example, one or more 

certified provider identities) and/or class of said 
information. 



Providing trusted verification that a consumer or 
other value chain participant is who she says she is 
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and/or is a member of one or more particular groups, 
classes and/or organizations. 

• Providing trusted verification that a group of value 
chain participants are collectively who they say they 

5 are, wherein a plurality of certificates from different 

parties are tested as an aggregate and where such 
aggregate of certain certificates is required under 
certain circumstances to use content and/or execute 
one or more control processes. 

1 0 • Automatically producing a certificate, representing 

authentication of a value chain or value chain portion, 
as a result of the confluence of a plurality of certain 
certificates. 

• Anticipating, through the use of rules and controls, 
1 5 allowable collections of certificates from plural 

parties that can form a certificate that virtually 
represents a specific group of certified parties and in 
the presence of certain certificates identifying two or 
more anticipated parties and/or parties who have met 

20 a certain criterion - e.g., sufficient transaction 

revenue, sufficient credit worthiness, etc. - a new 
certificate may be automatically generated and act as 
a composite certificate certifying the plural parties 
collective and coordinated presence, and wherein said 

25 certificate can be associated with certain rules and 
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controls allowing certain electronic activities such as 
usage of content and/or control processes in, for 
example, multiparty EDI, content distribution, trading 
system, and/or financial transaction systems. 

Generating one or more certificates at least in part as 
a result of rules and controls governance of certificate 
creation, wherein such generated one or more 
certificates are produced, for example, as a result of 
secure rules and controls based one or more 
instructions after the satisfaction of certain required 
criteria such as certain specific activities by each of 
plural parties — e.g. provision of one or more 
certificates and/or authorizations and/or usage 
activity and/or credit and/or payment activity and/or 
reporting activity and/or VDE supported electronic 
agreement activity (including, for example, electronic 
negotiation activity). 

Certifying other support services (e.g., financial 
clearinghouses, usage clearinghouses, rights and 
permissions clearinghouses, transaction authorities, 
and other certifying authorities, etc.). 

Certifying based on another certificate (e.g., identity) 
and an automatic secure database lookup which may 
be performed locally, across a distributed database 
arrangement, or remotely. 
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Providing non-automatic (i.e., at least in part human 
provided or assisted) services issuing more 
fundamental certificates (e.g., identity certificates) 
based on physical evidence in addition to automatic 
services for issuing dependent certificates. 

May use public key cryptography, private key, and/or 
secure VDE virtual networks to support, e.g. create, 
digital certificates. 

Can issue certificates that support the context for 
rights usage in an automatic, trusted, distributed, 
peer-to-peer secure electronic environment that 
supports chain of handling and control. 

As with other Distributed Commerce Utility services, 
supporting an unlimited variety of different business 
models and scenarios through general purpose, 
reusable, programmable, distributed, modular 
architecture. 

Can issue certificates that support control sets having 
elements whose use is dependent on presence and/or 
absence of specific, and/or class and/or non-specific, 
one or more digital certificates attesting to certain 
facts and where differing requirements may coexist 
regarding the presence or absence of certificates 
related to differing issues. 



194 



PCT/US96/14262 

Can issue one or more certificates that cooperate with 
conditional electronic control sets to grant certain 
rights only to certain consumers and/or other value 
chain participants, including, for example, consumers. 

Issuing replacements for expired certificates and 
supporting sophisticated time and/or usage and/or 
other event driven expiration (including termination) 
of certificates - for example, where criteria for such 
expiration may variety based upon specific 
certificates, classes of certificates, specific and/or • 
classes of users, user nodes, etc. 

Maintaining and distributing, including selectively 
distributing to distributed nodes revocation list 
information, based, for example, upon node 
distributed profiles and/or rules and controls. 

Distributing revocation list information among 
interoperable, peer-to-peer networked, Distributed 
Commerce Utility nodes on a time based, other event 
based manner, wherein information is selectively 
distributed to certain one or more nodes in 
accordance with agreed to revocation information 
requirements and/or where revocation information is 
non-selectively distributed to certain one or more 
nodes. 
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Receiving authority from secure chain of handling 
and control embodied in electronic control sets. 



• Distributing certificate authority functions across a 
network or other system (for example, every 

5 consumer node is potentially a certificate authority 

with respect to certain kinds of certificates; parents 
may be empowered to issue certificates for their 
children). 

• Organizing certificate authorities hierarchically, 

1 0 including allowing automatic verification of some 

certificate authorities (that is, their issued certificates 
and associated determinations regarding trustedness, 
appropriateness, etc.) through reliance on certificates 
issued by other certificate authorities at least in part 

1 5 for such purpose. 

• Granting authority and/or providing services to, or in 
conjunction with, one or more distributed certificate 
authority sub-clearinghouses whose operations may 
be located logically and/or physically elsewhere, such 

20 as within a company or government agency and/or 

within one or more jurisdictions and/or serving 
subsets of the overall business focus area of a senior 
certificate authority clearinghouse distributing and/or 
otherwise authorizing rights clearing functions across 

25 a system or network 
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Every consumer and/or certain or all other value 
chain participant nodes can potentially support a 
distributed certificate authority clearing service 
initiating its own, secure certificates and function in 
the context of the overall clearinghouse network, 
including, clearinghouse interoperation with one or 
more other participants interoperable nodes, and as 
elsewhere in this list, all activities employing VDE 
techniques as appropriate. 

Providing liability acceptance control (i.e., for 
insuring digital certificates based on the amount of 
liability accepted by the issuers)), and may include 
securely maintaining information regarding such 
liability acceptance and providing notices to 
recipients of such certificates regarding the liability 
protection afforded by such certificates, and may 
further include recipients of such insured certificates 
accepting, for example, through explicit VDE 
managed electronic acceptance or through implied 
acceptance by continuing, any liability above the 
insured amounts. 

May be organized hierarchically, peer-to-peer, or in a 
combined mode where responsibility for certificate 
authority activities may be distributed in differing 
fashions for differing commerce models and/or 
activities and/or value chains and where certain one 
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or more parties may be, for example, hierarchically 
more senior to other parties in one or more instances 
and hierarchically a peer or less senior in one or more 
other instances, that is the relationship among 
5 participants is programmable and may be set (and 

later modified) to represent one or more desired 
specific certificate authority arrangements for given 
commerce activities, value chains, or models. 

Figure 47 shows an example certifying authority 500 from a 

10 process viewpoint. In this example, certifying authority 500 
creates digital documents called certificates 504 that "certify" 
some fact, such as identity or class membership. For example a 
trusted third party certifying authority 500 can provide a secure 
digital assurance that a consumer is who she claims to be or has 

15 certain characteristics, attributes, class memberships, or the like. 
For example, some attributes may signify membership in a 
particular class (e.g., all employees of a certain company), those 
bom before a certain date, those having a certain physical 
disability, members of the faculty, administration or student body 

20 of a college, or retired members of the armed forces. 

In this example, digital certificates 504 issued by certifying 
authority 500 are used as a conveyor of the context of rights usage 
and transaction authorizations. As described in the Ginter et al. 
patent disclosure, certificates 504 are particularly powerful in the 

25 virtual distribution environment because they provide contexts for 
rights usage. For example, class-based certificate use and 
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automated, distributed governance of commerce rights may 
fundamentally enhance the efficiency of trusted networks. 
Suppose, for example, that a content publisher wants to charge 
commercial prices for a scientific journal subscription to all those 
5 but in higher education and is willing to give college and 
university students and professors a 20% discount. Digital 
certificates 504 issued by a trusted certifying authority 500 can be 
used to automatically provide assurances « within the context of 
distributed electronic network — that only people who are truly 
1 0 entitled to the discount will be able to exercise it (in this example, 
that only those certified as affiliated with an institution of higher 
education). 

In the Figure 47 example, certifying authority 500 may 
perform the following overall functions: 
15 • Fact collection and checking 522, 

• Certification generation 524, 

• Maintaining revocation lists 526, 

• Certificate and revocation list distribution 528, 

• Authentication 530, 

20 • Certificate renewal 532, 

• Authorization 534, 

• Replication 536, 

• Propagation 538, and 

• Archive 554. 

25 Certifying authority 500 may gather evidence 502 as a basis 

for which to issue digital certificates 504. In this example, 
evidence 502 may include other digital certificates 504' (e.g., so 
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that one certificate can build on another). The fact collection and 
checking function 522 may accept this evidence 502 as well as 
additional trustedness data 540 (e.g., information concerning 
compromised or previously misused certificates) Certificate 

5 generation function 524 may generate new digital certificates 504 
based upon this fact collection and checking process 522. 
Distribution function 528 may then distribute the new digital 
certificates 504, and issue bills 542 to compensate a certifying 
authority for undertaking the effort and liability that may be 

1 0 associated with issuing the certificate. 

Certifying authority 500 may also maintain a revocation list 
542 based on trustedness data 540 indicating, for example, 
certificates that have been compromised or that previously 
certified facts are no longer true (for example, Mr. Smith used to 

15 be a Stanford University professor but has since left the 

University's employ). The maintained revocation list function 
526 is important for providing a mechanism to ensure that "bad" 
certificates cannot continue to be used once they are known to be 
bad. Certificates 504 issued by certifying authority 500 can 

20 expire, and the certifying authority can (for example, for a fee) 
renew a previously issued certificate by performing certificate 
renewal function 532. The certifying authority 500 may maintain 
a record or database of the certificates it has issued, and this 
database can be distributed — which can benefit from replication 

25 function 536 and propagation function 538 to accurately and 
efficiently distribute the database across a number of different 
locations. 



Figure 48 shows an example architecture for certifying 
authority 500. In this example, certifying authority 500 may 
include a secure communications facility 544, an 
encryption/decryption processor 546, a billing system 548, a key 
5 generator 550, a query mechanism 552, and an electronic archive 
554. In this example, secure communications 544 is used to 
communicate with other electronic appliances 100 and/or other 
Commerce Utility Systems 90. Electronic archive 554 stores keys, 
certificates 504 and other information required to maintain the 

1 0 operation of certifying authority 500. Encryption/decryption 
processor 546 is used to create digital certificates 504 by using 
strong cryptographic techniques. Billing system 548 issues bills 
542. Query mechanism 552 is used to query electronic archive 
554. Key generator 550 is used to generate cryptographic keys the 

1 5 certifying authority 500 needs for its own operation. 

Figure 49 shows an example certifying authority process. 
In this example, a publisher may send an electronic secure 
container 1 52 to a consumer 95. To use certain permissions 1 88a 
in secure container 152, the consumer 95 may require a certificate 

20 from certifying authority 500 that certifies as to a particular fact 
about the consumer (e.g., the consumer is a United States citizen, 
the consumer is a retired member of the armed forces, the 
consumer is. over 1 8 years of age, etc.). The consumer may 
generate a request 502 to certifying authority 500 for issuance of 

25 an appropriate certificate. Certifying authority may check the 
evidence 502 the consumer 95 provides, or that some third party 
may provide, and ~ once the certificate authority 500 is satisfied - 
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- issue the consumer the required digital certificate 504. This 
digital certificate 504 may be used not only with the publisher's 
control set 188a, but with control sets from other rights holders 
that require certification of the same fact and that have agreed to 
5 trust certificate authority 500 as an issuer of certificates. 

Certifying authority 500 may communicate with consumer 
95 using secure containers 1 52. It may generate and provide a 
control set 188b with certificate 504. This control set 188b may 
control some aspect of usage of the certificate 504 (e.g., it may not 

1 0 be redistributed and/or modified) and/or to define a chain of 
handling and control for the issuance of further dependent 
certificates (e.g., parents give authority to issue certificates about- 
their offspring). 

One certificate authority 500 may be "proxied" to issue 

1 5 certificates on behalf of another - such as for example in a chain 
of handling and control defined by one or more electronic control 
sets 1 88. Distributing the certifying authority 500 across a 
number of different electronic appliances has certain advantages in 
terms of efficiency for example. Figure 50 shows one useful 

20 example of this distributed certificate issuance scenario. 

Figure 50 shows that a rightsholder 1 64 (and/or a rights and 
permissions clearinghouse 400) may request (e.g., by issuing 
electronic controls 188a within a secure container 1 52a) a 
certifying authority 500 to issue digital certificates 504(1) to 

25 accredited institutions of higher learning such as institution 1 060. 
Control set 1 88a may establish the policies and procedures 
necessary to ascertain whether in fact a particular institution is 
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duly accredited. Based on electronic controls 188a and evidence 
502 submitted by the institution 1060, the certifying authority 500 
may issue a digital certificate 504A attesting to the fact of 
accreditation. 

5 In order to take advantage of certificate 504A, a student, 

faculty member and/or staff member of institution 1060 may need 
to provide a further certificate attesting to the fact that he or she is 
affiliated with institution 1060. Instead of having certifying 
authority 500 issue a further certificate 504 to each student, 
1 0 faculty member and staff member of institution 1 060, it may be 
efficient and/or desirable for each institution 1060 holding a 
certificate 504A to issue dependent certificates 504(2) to its own 
faculty, staff and students. For example, institution 1060 may 
maintain a current list of all students, faculty and employees. 

1 5 Rather than requesting certifying authority 500 to issue a separate 
certificate 504(1) to each student, faculty member and employee 
of institution 1060, the institution may undertake this 
responsibility itself. 

For example, institution 1060 may elect to operate its own, 

20 distributed certifying authority 500A. In one example, certifying 
authority 500 may issue electronic controls 1 88b (subject to 
controls 188a issued by rights holder 164, for example) that 
delegate/to the institution's certifying authority 500A, the 
authority and responsibility to issue dependent certificates 504(2) 

25 within certain limits (e.g., attesting to a limited universe of facts 
such as for example "This person is officially associated with the 
institution 1060"). Such dependent certificates 504(2) could, for 

203 



™ PCT/US96/14262 

example, be copies of certificate 504(1) with an addendum stating 
that a particular person is associated with the institution 1 060 and 
stating a particular expiration date (e.g., the end of the current 
academic term). The institution's certifying authority 500A may 
5 then issue such dependent certificates 504(2) to each faculty 
member, student and staff member on its current roster. 

Recipients of certificates 504(2) may need a still further 
certificate 504(1) attesting to their identity. This is because 
certifying authority 500A issues certificates 504(2) attesting to the 

1 0 fact that a certain named person is affiliated with institution 1 060 
- not to the fact that a particular recipient of such a certificate is 
that person. The recipient may need to obtain this further 
"identity" certificate 504( 1 ) from a governmentally operated 
certifying authority 500 such as a state or federal government. 

1 5 Rightsholder 1 64 (and/or a rights and permissions 

clearinghouse 400 not shown) may issue control sets 1 88c for 
digital properties 166 that grant discounts or that provide other 
benefits to those who can provide a combination of valid digital 
certificates 504 attesting to their membership in the class 

20 "accredited higher education institution." Each student, faculty 
member and staff member of the institution 1060 who has 
received a certificate 504(2) may take advantage of these 
discounts or other benefits. Figure 50A illustrates how such 
different digital certificates can be used to support certificate- 

25 conditional controls 1 88 - that is, control sets whose elements are 
dependent on the presence or absence of certificates 504 that attest 
to certain facts. 
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In this Figure 50A example, one or more control sets 1 88c 
include a number of discrete controls 188(1) ... 1 88(N) applying 
to the same digital property 166 or group of properties, for 
example. Control 1 88(3) may provide additional and/or different 
5 rights to all students, faculty and staff members of Stanford 
University. In the Figure 50A example, multiple certificates can 
be used together to provide the requested certifications. For 
example, the certificates 504(1), 504(2), 504A shown in the Figure 
50 example can be used together to allow a particular person to 
1 0 take advantage of a discount offered to students, faculty and staff 
members of accredited institutions of higher learning. For 
example: 

• a certificate 504( 1) may attest to the fact that a certain 
person John Alexander is who he says he is. 

1 5 • another certificate 504A may attest to the fact that 

Stanford University is an accredited institute of higher 
learning, 

• another certificate 504(2) may attest to the fact that John 
Alexander is a student at Stanford University for the 

20 current academic semester. 

Each of these various certificates 504 can be issued by 
different certifying authorities 500. For example, one certifying 
authority 500 (e.g., operated by a governmental entity) might issue 
a certificate 504(1) certifying the consumer's identity, while 

25 another certifying authority may issue certificate 504(2) attesting 
as to student status, and a third certifying authority may issue the 
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certificate attesting to the fact that Stanford is an accredited 
University (see Figure 50). 

As an additional example, a control set element 1 88( 1 ) 
shown in Figure 50A may provide a certain benefit for California 
5 . residents. Its condition may be satisfied by the consumer 

presenting a digital certificate 504(3) certifying residency (e.g., in 
combination with the "identity" certificate 504(1)). A still further 
permission 1 80(N) shown in Figure 50A might be satisfied by 
presenting a certificate 504(5) indicating U.S. citizenship. Such 

10 certificates 504(3), 504(5) that warrant that a given person is 

subject to one or more jurisdictions (for example, a resident of, or 
doing business in a particular city, state, nation, or other political 
unit — and therefore, subject to that unit's sales, income, or other 
taxes, or subject to certain administrative fees) are particularly 

15 useful for interstate and/or international commerce transactions. 
For example, a certifying authority 500 might issue a certificate 
504 to a financial clearinghouse 200 in the United Kingdom. This 
certificate 504 could be used in conjunction with control sets 1 88 
distributed by rightsholders and/or a rights and permissions 

20 clearinghouse 400 specifying that only United Kingdom financial 
clearinghouses 200 are authorized to accept payment in pounds 
sterling. A customer wishing to pay in pounds sterling will only be 
able to complete the payment transaction if the financial 
clearinghouse being used has the appropriate UK certificate. This 

25 UK clearinghouse might then pay appropriate UK taxes - 
relieving the provider from the burden of having to determine 
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which of his or her transactions were subject to UK tax payments 
and which were not. 

Figure 50A also shows a further certificate 504(4) certifying 
that a certain person is married to a certain other person. To use 
5 certificate 504(4), it may also be necessary to present the first 
certificate 504(1) certifying identity. Such certificates attesting to 
relationship between individual people or between people and 
organizations are useful in allowing, for example, family members 
to use the certificates of other family members (e.g., a person can 
1 0 obtain a benefit based on his or her spouse's or parents' certified 
credential(s)). 

Figures 5 1-5 ID show example detailed formats of various 
digital certificates 504. The Figure 51 A digital certificate 504(1 ) 
may certify that a person is who he says he is. This certificate 
1 5 504( 1 ) might include, for example: 

• a field 560(1) stating the person's name, 

• a field 560(2) specifying the person's date of birth, 

• an expiration field 560(3) specifying when the digital 
certificate expires, 

20 • a public key 560(4) corresponding to the person's public 

key, an ID code 560(5) (which in this example could be a 
hash of the public key field 560(4)), and 

• a check sum field 560(6) providing an error checking 
ability. 

25 Digital certificate 504(1) is encrypted in this example by the 

certifying authority 500 using the certifying authority's private 
key of a public key-private key cryptosystem pair, such as RSA or 
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El Gamal. The certifying authority 500's corresponding public 
key can be made public (e T g., by publishing it in several publicly 
accessible sites on the World Wide Web or in another widely 
distributed context), or it could remain secret and never be 
5 exposed outside of protected processing environments 1 54. In 
either case, successful decryption of the digital certificate 504(1) 
to reveal the original clear text information provides a high degree 
of assurance that the digital certificate was issued by certifying 
authority 500 (presuming that the certifying authority's private 

1 0 key has not been compromised). 

Expiration field 560(3) is useful because people who skip 
checks of revocation lists have at least some assurance that a 
certificate is good if it must be renewed periodically. Expiration 
date field 560(3) provides an additional safeguard by insuring that 

1 5 certificates do not last forever — allowing certifying authorities 
500 to use different cryptographic key pairs for example to 
provide overall integrity and trustedness of the certification 
process. Changing the certifying authority 500's key pair reduces 
the incentives for an adversary to break a given key, because the 

20 amount of information protected by that key is limited, and the 
fraudulent use of a compromised key will only have a limited time 
of effectiveness. Furthermore, (currently) unexpected advances in 
mathematics may render some cryptographic algorithms useless, 
since they rely on (currently) theoretically intractable 

25 computations. A built in mechanism for changing the certifying 
authority 500's keys allows the impact of such breakdowns to be 
limited in duration if new algorithms are used for reissued 
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certificates (alternatively, this risk can also be addressed by using 
multiple asymmetric key pairs generated in accordance with 
different algorithms to sign and validate keys, at the cost of 
additional decryption time). 
5 Figures 5 1 B, 5 1 C and 5 ID show additional digital 

certificate examples containing different sorts of information (e.g., 
professional credential field 560(7) in the case of certificate 
504(5), address field information 560(8) in the case of certificate 
504(3), and student credentials field 504(9) in the case of student 
1 0 certificate 504(2)). These certificates 504(2), 504(3), 504(5) are 
tied to identity certificate 504(1) via the common ID field 560(5), " 
and both the identity certificate and the independent certificate 
would generally need to be presented together. 

Figure 5 IE shows how an example digital certificate issued 
1 5 by one certifying authority can - in conjunction with a trusted 
database - be the basis for another certifying authority to grant 
another certificate. One certifying authority 500A can, for 
example, validate user identity and create the identity certificate 
504(1) shown in Figure 5 1A. The user can submit this identity 
20 certificate 504(1 ) to another certifying authority 500B that has a 
data base 554a of people and/or organizations who have a 
particular attribute. For example, certifying authority 500B may 
be operated by a professional organization that maintains an 
internal database 554a. Certifying authority 500B will trust the 
25 contents of this internal database 554a because the certifying 
authority 500B maintains it and keeps it accurate. 
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By comparing the identity information in the Figure 51 A 
certificate with the contents of the trusted database 554a, 
certifying authority 500B can issue the Figure 5 IB certificate 
without requiring any physical evidence from the owner of the 
5 Figure 5 1 A certificate. This solves an important problem of 
requiring the user to "show up" each time he needs a highly 
trusted certificate — and also allows the second certificate- 
generating the process to be automated. 

Figure 5 IE also shows that the certificate 504(2) issued by 

10 certifying authority 500B may be (along with identity certificate 
504(1)) a sufficient basis for a further certifying authority 500C to 
issue a further certificate 504(3) based on its own lookup in a - : 
trusted database 554b. 

Another example would be a corporation that has proven its 

1 5 identity to the Secretary of State in the jurisdiction in which it is 
organized. If this corporation has passed muster to handle 
hazardous material it could submit its certificate of identity 504(1 ) 
from the Secretary of State (which in this case would comprise 
certifying authority 500A) to the agency (certifying authority 

20 500B responsible for maintaining the database 554a of which 
companies are currently qualified and authorized to handle 
hazardous materials. The certifying authority 500B could then 
issue a certificate 504(2) attesting to this fact in an entirely 
automated way if desired. 

25 Insert before heading on p 219 Secure Directory Services 

(Figure 52 shows) 
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Certification to Allow Participants to Act as Ag ents of an 
Entity 

Sometimes, one or more participants in a particular value 
chain, or having a particular relationship with other participants, 
5 need to be authorized to act on behalf of the collection of 

participants. For example, several parties may wish to act based 
on authorization from the partnership or joint venture of which 
they are a member - or all participants within a particular value 
chain may need to act for the value chain as a whole. Each of the 

1 0 participants receiving such authority from the entity may need 
authorization from the entity to act. 

The present invention provides a mechanism in which 
digital certificates 504 may be used to create a "virtual entity" that 
can grant any combination of participants any combination of the 

1 5 same or different powers to exercise defined powers under 
controlled conditions of use. More particularly, a digital 
certificate grants each participant in a virtual entity the power to 
act on behalf of the entity - within the constraints of the 
conditions of use and further with any consequences defined in the 

20 conditions of use specified by electronic controls associated with 
the container. 

Figure 5 IF shows an example electronic container 152 that 
encases the following information: 

a value 564 that identifies the "virtual entity," 
25 signatures 566(1 )-566(N) - one for each member of the 

entity, 

other information 568 pertaining to the entity, 
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digital certificates 504(1 )-504(N) - one for each member of 
the entity, and 

control information 1 88 that specifies powers (e.g., rights or 
permissions) and "conditions of use." 
5 Value 564 provides an identifier that uniquely identifies the 

entity. The "other information" field 568 may provide further 
information concerning the entity (e.g., the name of the entity, the 
name and address of each participant, the expiration date on which 
the entity ceases to exist, and other information). Signatures 

1 0 566( 1 )-566(N) are like signatures on a partnership agreement - 
each member of the virtual entity affixes his or her "signature" to 
indicate assent to be a member of the entity and assent to the 
conditions being granted to each participant. 

Container 1 52 in this example further includes an electronic 

1 5 control set 1 88 describing conditions under which the power may 
be exercised. Controls 188 define the power(s) granted to each of 
the participants - including (in this example) conditions or 
limitations for exercising these powers. Controls 1 88 may provide 
the same powers and/or conditions of use for each participant, or 

20 they may provide different powers and/or conditions of use for 
each participant. 

For example, controls 1 88 may grant each participant in a 
virtual entity the power to act as a certifying authority 500 on 
behalf of the entity. In this particular example, controls 188 may 

25 allow each party of the virtual entity to make certificates on behalf 
of the virtual entity - within the constraints of the conditions of 
use and further with the consequences defined in the conditions of 
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use specified by controls. As discussed above, the right to grant 
certificates is only an example - any type of electronic rights) or 
permission(s) could be granted based on any type of electronic 
condition(s) of use. 
5 Figure 5 1 G shows one example process for creating the 

Figure 5 1 F container 1 52. In this example, the parties to the 
virtual entity may negotiate control information governing 
collective action based on, for example, the electronic negotiation 
techniques shown in Figures 75A-76B of the Ginter et al. patent 

1 0 specification (Figure 5 1G, block 570). The resulting control 
information 188 specifies "conditions of use" such as the rights 
that may be exercised by each participant in the entity, and 
limitations on each of those rights (which may be defined on a 
participant-by-participant basis). 

1 5 The participant initiating issuance of digital container 1 52 

(actually, the participant's protected processing environment 1 54) 
may select a random value for use as entity identifier value 564 
(Figure 51G, block 572). The participant's PPE 154 may next 
create the certificate information for the virtual entity by 

20 associating the entity identifier value 564 with other information 
568 (Figure 5 1G, block 574). The participant's PPE 1 54 may next 
sign the virtual entity certificate information to indicate the 
participant's assent to be a member of the virtual entity and 
assents to the conditions of use control information 188 (Figure 

25 5 1G, block 576). 

The participant's PPE 154 may then make electronic 
container 152, and place into it the control information 1 88, the 
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virtual entity certificate information 564, 566, 568, and the 
participant's own certificate 504 specifying a cryptographic key 
the participant may use to exercise rights (Figure 5 1G, block 578). 
The participant may then determine whether any more 
5 participants need to be added to the entity certificate (Figure 5 1 G, 
decision block 580). If yes, the container 152 may be transmitted 
(Figure 51G, block 582) to another participant member of the 
virtual entity and accessed and validated by that next participant 
(Figure 51G, blocks 584, 586). The next participant may similarly 

1 0 sign the virtual entity certificate information by adding his 

signature 566(2) to the list - indicating the she also agrees with the 
controls 188 and agrees to join the virtual entity (Figure 51G, 
block 588). This new information is used to add to and/or replace 
the entity certificate information 564, 566, 568 (Figure 5 1G, 

1 5 block 590). This next participant also adds their own certificate 
504(2) to the container 152 (Figure 5 1G, block 592). 

Steps 580-592 may be repeated until container 1 52 has been 
signed by each participant within the virtual entity ("no" exit to 
decision block 580). The completed container 152 may then be 

20 transmitted to all participants (Figure 5 1 G, block 594). 

Figure 51H shows an example process a virtual entity 
participant may use to exercise powers on behalf the virtual entity 
based on the controls 188 shown in Figure 5 IF. The Figure 5 IH 
example process is performed by the participant's protected 

25 processing environment 154 based on a request. The participant's 
protected processing environment 154 writes an audit record 
(Figure 51H, block 594a) and then evaluates the request using the 



conditions of use specified by controls 1 88 (Figure 5 1H, block 
594b). If the request is permitted by the controls 1 88 ("yes" exit 
to decision block 594c, Figure 51H), the participant's protected 
processing environment 154 accesses the virtual entity value 564 
5 from container 1 52 (Figure 5 1 H, block 594d) and uses the control 
information 1 88 associated with conditions of use to fulfill the 
request and perform appropriate consequences (Figure 51H, block 
594e). In one example, the participant's protected processing 
environment 154 may act as a certifying authority 500 on behalf 

10 of the virtual entity by issuing a digital certificate 504 in 
accordance with the conditions of use - digitally signing the 
digital certificate by encrypting the entity identifier value 564 with 
a cryptographic key corresponding to the participant's own 
certificate 504 within container 1 52, and making the digital 

1 5 certificate part of the newly issued certificate. The example may 
then write additional* audit information 594H reporting on the 
action it has taken. 

If the requested action is not permitted by controls 1 88 
(Figure 5 1H, "no" exit to decision block 594c), the example 

20 Figure 5 1 H process determines whether the error is critical 

(decision block 594f). If the error is critical ("yes" exit to decision 
block 594 f), the process may disable further use of the information 
within container 152 (block 594g), writes additional audit 
information (block 594h), and then stops (Figure 5 1H, block 

25 594i). If the error is not critical ("no" exit to decision block 594f), 
the protected processing environment 154 writes additional audit 
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information (block 594h) and may then end this task (Figure 5 1H, 
block 594i). 

The processes and techniques shown in Figures 5 1 F-5 1 H 
have a variety of different uses. As one example, suppose that a 

5 • . . first publisher publishes a derivative work including his own 
content and content provided by a second publisher. The two 
- publishers may form a virtual entity that allows the first publisher 
to act on behalf of the entity - but only in accordance with the 
conditions of use negotiated and agreed upon by both partners. 

1 0 For example, the second publisher may be willing to allow the 
first publisher to republish the second publisher's content and to 
allow excerpting and anthologizing of that content by consumers 
95 - but only if the consumers present an appropriate certificate 
504 issued by the virtual entity attesting to the fact that the 

15 consumer is permitted to exercise that right. For example, only 
special subscribers having certain characteristics may be entitled 
to receive a certificate 504. The techniques above allow the first 
publisher to issue certificates 504 to subscribers on behalf of the 
virtual entity comprising both the first and second publishers. The 

20 second publisher can be confidant that the first publisher will only 
issue certificates in accordance with the conditions of use 
negotiated and agreed by both publishers. 

Another example is a manufacturing process comprising 
multiple participants. The conditions of use provided by controls 

25 1 88 may allow any of the value chain participants in the 

manufacturing process value chain to perform certain actions on 
behalf of the value chain as a whole. For example, a materials 
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manufacturer, a finished goods supplier and the shipping company 
that transports materials between them may for a virtual entity. 
This virtual entity may then submit a control set to a transaction 
authority that describes a process that describes all three 
5 participants acting in concert. For example, the control set created 
in accordance with the conditions of use applicable to their virtual 
entity might permit a unified presentation of materials 
requirements, finished appearance and delivery schedule, as one 
simple example. 

1 0 In another example, a semiconductor company, a systems 

integrator, and three different suppliers of software may form a 
virtual entity supporting the semiconductor company's chip 
design, simulation, and design testing applications. In this 
example, certificates may be issued to each company comprising 

15 this example entity and to particular individuals within each of the 
companies. Rules and controls negotiated among the companies 
may specify who has access to which parts of the software 
applications and associated databases and who may make 
modifications to the software and/or data. In this way, the 

20 semiconductor company can authorize access to outside 
contractors and/or suppliers and to specific individuals 
representing those outside companies. These individuals may be 
authorized just enough access to solve typical problems and 
perform system maintenance tasks. Also, they may be granted 

25 additional rights (authorizations) for a limited period of time in 
order to resolve specific problems requiring for resolution access 
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to certain executable^ and/or data not included in their default 
permissions. 

The virtual entity feature of the present invention 
represents, in part, an extension that builds upon the chain of 
handling and control techniques disclosed in Ginter et al. For 
example, certificates produced in accordance with this aspect of 
the present invention can use capabilities of a VDE chain of 
handling and control to manage a chain of certificates. 

Secure Directory Services 

Figure 52 shows an example of a secure directory services 
Commerce Utility System 600. Secure directory services may 
securely provide electronic and/or other directory information 
such as names, addresses, public keys, certificates and the like. 
Transmittal of such information securely (e.g., through the use of, 
in the preferred embodiment, the Virtual Distribution 
Environment) helps prevent eavesdropping, helps ensures 
confidentiality, and provides significant infrastructure support by 
enabling important participant interaction efficiencies. 

In more detail, secure directory services provided in 
accordance with these inventions may provide the following 
example advantageous features and functions: 

• Securely and reliably providing directory information 
based on a variety of different parameters, including 
various classification information. 
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May securely provide consumer's, content provider's, 
clearinghouse's and/or other party's electronic 
address(es) and/or other communication pathway(s) 
based on name, function, physical location, and/or 
other attributes. 

May provide consumer's, content provider's, 
clearinghouse's and/or other party's public key(s) 
and/or certificate(s) based on, for example, name, 
function, physical location, and/or other attributes. 

Protects, and where appropriate may conceal, identity 
related information while efficiently managing and/or 
automating the confidential communicating of 
requests and responses in secure containers. 

Using secure containers and rules and controls to 
guarantee integrity and non-reputability of content. 

Receiving authority from secure chain of handling 
and control embodied in electronic control sets. 

Distributing secure directory services functions 
across a network or other system (for example, every 
consumer and/or other value chain participant node is 
potentially a distributed secure directory service 
initiating its own, secure directory service 
transactions directly with one or more other 
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participants using VDE as described in the Ginter, et 
al. patent specification). 

Granting authority and/or providing services to, or in 
conjunction with, one or more distributed secure 
directory services sub-clearinghouses whose 
operations may be located logically and/or physically 
elsewhere, such as within a company or government 
agency and/or within one or more jurisdictions and/or 
serving subsets of the overall business focus area of a 
senior directory service authority distributing and/or 
otherwise authorizing secure directly service 
functions across a system or network. 

Every consumer and/or certain or all other value 
chain participant nodes can potentially support a 
secure directory services authority providing naming 
and related services and function in the context of the 
overall naming services network, including 
interoperation with one or more other participants 
interoperable nodes, and as elsewhere in this list, all 
activities employing VDE techniques as appropriate. 

May be organized hierarchically to delegate 
responsibility for, and operation of secure directory 
services for a subset of the overall directory based on 
name, function, physical location, and/or other 
attributes. 
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• May be organized hierarchically to provide a 
directory of directories, for example. 

• May be organized hierarchically, peer-to-peer, or in a 
combined mode where responsibility for directory 

5 services may be distributed in differing fashions for 

differing commerce models and/or activities and/or 
value chains and where certain one or more parties 
may be, for example, hierarchically more senior to 
other parties in one or more instances and 

1 0 hierarchically a peer or less senior in one or more 

other instances, that is the relationship among 
participants is programmable and may be set (and 
later modified) to one or more desired specific 
directory service arrangements for given commerce 

1 5 activities, value chains, and/or models. 

Figure 52 shows an example secure directory services 600 
from a process point of view. In this example, secure directory 
services 600 is an archive that securely keeps track of directory 
information relating to consumers, value chain participants and/or 
20 electronic appliances, and securely provides this information upon 
qualified demands. In this example, secure directory services 600 
may provide the following functions: 

• Database management 606, 

• Database search/retrieval 608, 
25 • Database replication 610, 
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• Database propagation 612, 

• Authentication 614, and 

• Authorization 616. 

Database 606 may be accessed by search and retrieval 
5 engine 608 which takes consumer-provided input information as a 
source and uses it to retrieve records that are relevant. For 
example, secure directory services 600 may receive identities 618 
of individuals, organizations, services and/or devices; electronic 
addresses 620; certificate 622; and/or keys 624. This information 

10 may be stored in database 606. 

In response to requests 602, secure directory services search 
and retrieval engine 608 may access database 606 to retrieve 
additional information (for example, the electronic mail address of , 
a certain individual or organization, the public key of a certain 

1 S individual, the identity of a person having a certain electronic mail 
address, the identity and address of a person having a certain 
public key, etc.). 

Additionally, secure directory services 600 may return 
access controls, audit requirements and the like. For example, a 

20 user may be required to present valid credentials (e.g., a certificate 
504) to access the internal email addresses of a corporation. 
Certain fields of information known to the database 606 may not 
be available to all comers (e.g., the office location or a particular 
employee, their home directory(ies) on the company's servers, 

25 etc.; or a consumer's physical address may be available to people 

that present a certificate 504 issued by the consumer acting as his 

own certificate authority 500, but no one else. These controls can 
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be specified in secure containers that carry the information to the 
secure directory service 600. 

When the information is provided to requesters, they may 
be required to use the information only in authorized ways. For 
5 example, they may be allowed to use the information to formulate 
email messages, but not excerpt a physical address for a mailing 
list. These restrictions can be enforced by controls 1 88b the 
secure directory services 600 associates with the information it 
provides. 

10 As shown in Figure 53, secure directory services 600 may 

provide a database 606 and search and retrieval engine 608 in 
addition to a secure communications facility 626. The 
architecture of secure directory services 600 may be based on 
Figures 12 and 13 of the Ginter et al. patent disclosure. 

1 5 Figure 54 shows an example secure directory service 

process performed by secure directory services 600. In this 
example, a sender 95(1) wants to send a message to a receiver 
95(2). The senders and receivers could be electronic appliances 
100 owned by consumers, clearinghouses, or the like. Sender 

20 95(1) may send an address request 602 to secure directory services 
600 providing certain information and requesting other 
information. In response, secure directory services 600 provide 
the requested information to sender 95(1) - who may use the 
information to send a message to receiver 95(2). In this example, 

25 both the address request 602 and the responsive information 604 
are contained within secure electronic containers 1 52 in order to 
maintain the confidentiality and integrity of the requests and 
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responses. In this way, for example, outside eavesdroppers cannot 
tell who sender 95(1) wants to communicate with or what 
information he or she needs to perform the communications — 
and the directory responses cannot be "spoofed" to direct the 
5 requested messages to another location. In addition, as discussed 
above, directory services 600 can include controls 1 88 along with 
its responses and/or request or require controls 1 88 as part of its 
input. 

Transaction Authority 700 

1 0 Figure 55 shows an example Transaction Authority Commerce 
Utility System 700. These inventions also enable secure 
"transaction authority" capabilities providing the following overall 
functions: 

• Securely validating, certifying, and/or auditing events 
15 (including, for example, authenticating, and, for 

example, for non-repudiation purposes) in an overall 
multi-event transaction or chain of handling and control 
process; 

• Securely storing, validating, certifying, and/or 
20 distributing control sets (including, for example, 

authenticating, and, for example, for non-repudiation 
purposes) for multi-event transaction or chain of 
handling and control processes; 

• Issuing requirements for any or all of the transaction 
25 and/or process steps; and 
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• If desired, actively participating in the transaction or 
process (e.g., through managing, directing, 
intermediating, arbitrating, initiating, etc., including 
participating in models employing reciprocal control 
methods and distributed, automated events for, for 
example, distributed computing, process management, 
EDI, reference to currency, etc.) 

• Can certify steps and/or pathways, including certifying 
proper routing for electronic information through 
transaction authority telecommunication switches 
adapted to certify certain information and wherein 
certificates certify that a required route was followed 
and/or the sending of such electronic information was 
pursuant to certain stipulated rules and controls, for 
example acquiring certain archiving information and/or 
not exceeding budget and/or other limits and/or 
restrictions for, for example: numbers of "shipped" 
information containers in a given period of time, value of 
electronic currency contained within (represented by) a 
current container and/or by containers over a certain 
period of time, financial amount committed in purchase 
order, proper ordering authority, etc. 

The transaction authority may simply be a secure, watchful 
bystander to, and certifier of, the electronic transaction and/or 
transaction step (in a sequence of overall transaction steps), it may 
be a secure facilitator of a secure plural-party electronic 
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transaction, and/or it may actively and directly participate in the 
electronic transaction. 



In more detail, a transaction authority in accordance with these 
inventions may provide the following advantageous features 
and/or functions: 

• Securely maintaining and validating event 
notification information pertaining to a multi-stage 
transaction and/or chain of handling and control 
process(es). 

• May enforce, through requirements for its 
certification or authentication, a sequence of required 
transaction and/or chain of handling and control 
processes steps based on component representation of 
elements of a business process, where, for example, 
one or more transaction authorities respectively 
certify and/or authenticate one or more specific 
events at one or more step "locations" in a transaction 
sequence. 

• May form an overall transaction control set from a 

. number of discrete sub-control sets contributed, for 
example, by a number of different participants. 

• Using reciprocal methods to coordinate required 
transaction events, including for example, sequence 
of events, between value chain participants. 
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Receiving authority from secure chain of handling 
and control embodied in electronic control sets. 

May intervene to actively manage transactions and/or 
chain of handling and control processes. 

Can coordinate workflow and/or chain of handling 
and control processes and/or other business 
processes. 

Can provide automatic and efficient management 
based on a trusted, secure distributed electronic 
commerce environment, including certifying and/or 
authenticating steps in distributed proprietary 
information, EDI, financial transaction, and/or trading 
system value chain activities that very substantially 
improves security for distributed rights management, 
wherein such security can meet or exceed the security 
available with centralized, online commerce models. 

May manage at least a portion of the transactions 
within and/or between value chain participants (e.g., 
organizations, individual consumers, virtual 
groupings). 

May specify and/or monitor, at least in part through 
the use of rules and controls, conditions of 
satisfaction for, and/or consequences of, atomic 
transactions. 
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May direct what happens based on error conditions 
and/or transaction profile analysis (e.g., through use 
of an inference engine and/or expert system). 

Can provide confidential coordination of security, 
routing, prioritizing, and negotiating processes 
allowing different, distributed parties to work 
efficiently together through a confidential, trusted 
interface. 

Providing notarization, validation, certification, 
and/or delivery, as appropriate, for secure document 
and/or process control. 

Can certify steps and/or pathways, including 
certifying proper routing for electronic information 
through transaction authority telecommunication 
switches adapted to certify certain information and 
wherein certificates certify that a proper route was 
followed and the sending of such electronic 
information was pursuant to certain stipulated rules 
and controls, for example not exceeding budget or 
other limits for: numbers of "shipped" information 
containers in a given period of time, value of 
electronic currency represented by current container 
and/or by containers over a certain period of time, 
financial amount committed in purchase order, proper 
ordering authority, etc., are issued to satisfy 
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requirements regarding receiving a proper such 
certification or authentication at a node receiving 
such routed information. 

• Distributing transaction authority functions across a 
network or other system (for example, every 
consumer and/or other value chain participant node is 
potentially a distributed usage clearing service at least 
in part initiating its own, transaction authority 
functions, and wherein said participant node may 
communicate usage information directly to one or 
more other participants) and in accordance with rules 
and controls and other VDE techniques as described 
in the Ginter, et al patent specification. 

• May provide arbitration, mediation and negotiation 
services, electronic or otherwise. 

Figure 55 shows a particular example transaction authority 
700 from an overall function viewpoint. Transaction authority 
700 provides, among other things, a secure auditing facility for 
maintaining the current state of an overall transaction or process 
based upon event notifications it receives from the participants in 
the transaction. 

In this specific example, transaction authority 700 performs 
the following functions: 

• Event notification collection 730, 

• Validated event database management 732, 
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• Requirement generation 734, 

• Secure authenticated auditing 736, 

• Reporting 738, 

• Notifying 740, 

5 • Replication 742, and 

• Propagation 744. 

In this example, transaction authority 700 receives 
notifications that events have occurred in the form of event 
notifications 748 which may be carried in one or more secure 

10 electronic containers 152. Event notification collection process 
730 collects these event notifications 748 and may store them in a 
validated event database 732. Transaction authority 700 may 
generate additional notifications 748' based on its validated event 
database 732, and may also issue responses 750 indicating the 

1 5 current status of a transaction or process in response to requests 
752 and/or based on other requirements. In addition, transaction 
authority 700 may generate and output audit records 754 
indicating the progress and status of transactions or processes 
based upon the contents of its validated events database 732 as 

20 analyzed by auditing function 736. Transaction authority 700 may 
also issue reports 756 based on its reporting function 738. 
Validated event database 732 may be a distributed event 
notification database, in which case replication process 742 and 
propagation process 744 are used to maintain and update the 

25 database in a distributed manner. 

Another major function of transaction authority 700 in this 
example is to issue new or modified event requirements 758 that 
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can be used to control or influence an overall process or 
transaction. Transaction authority 700 may receive control set 
188, prices and permissions 188', event flow requirements 760 
and/or process routing requirements 762. Both event flow 
5 requirements 760 and process routing requirements 762 can be 
specified in one or more control sets. In response to this 
information and the validated event database 732 contents, 
transaction authority 700 may use its requirement generation 
process 734 to create new or modified event requirements 758. 

1 0 Transaction authority 700 may also create new or modified control 
sets 1 88" and new or modified prices and/or permissions 1 88'". 
Transaction authority 700 may use financial statements 764 as an 
input to its secure auditing function 736. 

Figure 56 shows an example architecture for transaction 

1 5 authority 700. In this example, transaction authority 700 (which 
may be based on the VDE rights operating system ("ROS") 
architecture shown in Ginter et al. Figures 12 and 13) includes a 
secure communications facility 770, a database and transaction 
processor 772, process control logic 774, routing tables 776, and 

20 an adaptive control set database 778 (these functions could be 
performed by methods at one or more control sites). In addition, 
transaction authority 700 may also include a document notarizer 
780 including a seal generator 782, a digital time stamp generator 
784, and a fingerprint/watermark generator 786. 

25 Secure communications facility 770 permits transaction 

authority 700 to communicate in a secure manner over electronic 
network 150 (for example, via secure electronic containers 152). 
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Database and transaction processor 772 performs most of the 
processes shown in Figure 55. Adaptive control set database 778 
may perform the validated event database function. Routing 
tables 776 may be used as part of requirement generation function 
5 734 to route appropriate messages to appropriate entities. 

Process control logic 774 may include an inference engine 
or expert system for use in handling error conditions not fully 
anticipated or specified by the event flow requirements 760 and/or 
process routing requirements 762. Process control logic 774 

10 might operate based on rule based principles, fuzzy logic, neural 
networks, or a combination of some or all of these — or any other 
method of process control logic. Process control logic 774 
determines the next event that is to occur within the overall 
transaction or process. 

1 5 Document notarizer 780 may be used to provide 

authenticated document generation, for example, to affix digital 
seals and/or stenographic information to written and/or digital 
documents. 

Figure 57 shows an example transaction authority process. 

20 In this simplified example, transaction authority 700 may be an 
entity internal to a corporation used to securely audit and direct an 
overall goods delivery process. In this example, a customer 95 
issues an order 788 for goods. This order 788 is received by an 
order receiving department 704 which issues an order event 71 0 to 

25 transaction authority 700. In response to this order event 7 1 0, 
transaction authority 700 may issue rules and/or requirements in 
the form of one or more electronic control sets 1 88 specifying how 



the order receiving department 704 is to handle the order. These 
rules 188 may specify, for example, a sequence of chain and 
handling that also directs the activities of a fulfillment department 
709 A, a warehouse 709B, a transportation company 726, and a 
5 payment collection department 709C. The rules 1 88— which may 
be passed from one department to the other within secure 
electronic containers 152 - thus specifies the requirements and 
overall process flow of the transaction that is to occur. Each 
department may then pass the secure controls 188 along to the 

1 0 next department, with routing being directed by the rules 

themselves and/or by transaction authority 700. Each department 
may also issue event notifications 748 alerting transaction 
authority 700 of the current status of the overall process. 
Transaction authority 700 may store this status information within 

1 5 its secure validated event database 732 for auditing purposes 

and/or to permit the transaction authority to direct the next step in 
the process. 

Transaction authority 700 can, for example, use the 
interaction models shown in Figures 17E-1 through 17E-4 to 

20 interaction with an ongoing transaction or process. One 

particularly useful scenario for transaction authority 700 is to 
manage a process performed by multiple parties, such as 
corporations working on a joint venture or other common 
objective. In this type of business scenario, multiple corporations 

25 may be working toward a common overall goal but may 
themselves have their own objectives internally such as, for 
example, protecting their own confidential trade secret 
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information. Transaction authority 700 can be used as an 
independent third party mediator/arbitrator to coordinate activities 
between the multiple corporations without requiring any of the 
corporations to expose detailed process information to anyone 
5 other than transaction authority 700. 

For example, transaction authority 700 can generate control 
sets specifying event flow and/or process routing requirements 
758 and/or control sets 188 that mean different things in different 
contexts. As an example, a control set that transaction authority 

10 700 issues might cause one corporation to perform one step and 
another corporation to perform another step — with each 
corporation never learning the particular step or sequence of steps 
being performed by the other corporation. Thus, transaction 
authority 700 can develop control sets 1 88 that can be used to 

1 5 provide only partial disclosure between different individual or 
corporate actors. 

Figures 58A and 58B show example steps and processes 
performed by transaction authority 700 to perform an "atomic 
transaction". In this example, transaction authority 700 performs 

20 a role that is somewhat analogous to the coach of a football team. 
By accepting the skill set and requirements of each individual 
"player" and linking them together into an overall "game plan," 
the transaction authority 700 can involve any number of value 
chain participants in an overall "atomic" transaction. 

25 In this example, each value chain participant 1 64( 1 ), . . . 

164(N) in a process administered by transaction authority 700 
could contribute a control set 188(1), . . . 1 88(N) specifying or 



governing the participant's own business requirements, limitations 
and processes for the transaction (Figures 58A and 58B, block 
750). These individual control sets 188(1), 188(N) specify how 
each individual participant performs its own role. Each participant 
5 1 64( 1 ) . . . 1 64(N) knows its own role in the overall transaction, 
but may have no idea what roles others may play or have any clear 
idea how to form a "team" of other participants - and so these 
individual control sets 188(1), 188(N) typically describe only sub- 
transactions and may not take overall transaction considerations 

1 0 into account 

Transaction authority 700 also receives another control set 
1 88X specifying how to link the various participants' control sets 
together into overall transaction processes with requirements and 
limitations (Figures 58A and 58B, block 752). This overall 

1 5 transaction control set 1 88 Y specifies how to resolve conflicts 
between the sub-transaction control sets 188(1), 188(N) provided 
by the individual participants (this could involve, for example, an 
electronic negotiation process 798 as shown in Figures 75 A-76A 
of the Ginter et al. patent disclosure). The transaction authority 

20 700 combines the participant's individual control sets - tying them 
together with additional logic to create an overall transaction 
control superset 188Y (Figures 58A and 58B, block 752). 
Transaction authority stores the resulting control superset 1 88Y in 
local storage (Figure 58B, block 754). This overall control 

25 superset controls how transaction authority 700 processes events 
to perform an "atomic" transaction. 
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Upon receipt of an incoming event requiring processing 
(Figure 58B, block 756), transaction authority 700 may activate 
the overall transaction control superset 188Y (Figure 58B, block 
758). The transaction authority 700 may then deliver 
5 corresponding reciprocal control sets corresponding to portions of 
the overall transaction control superset 1 88Y to each participant in 
the transaction - thereby enabling each participant to 
communicate with the superset (Figure 58B, block 760). 
Alternatively, each participant in this example may - at the time it 

1 0 contributes its control set 1 88(1 ), 1 88(N) to transaction authority 
700 — maintain a reciprocal control set that can communicate with 
the control set the participant sent to transaction authority 700. 

Transaction authority 700 may then begin monitoring 
events received using the activated control superset (Figure 58B, 

1 5 block 762). If the incoming event is not an error condition ("N" 
exit to Figure 58B decision block 764), then transaction authority 
700 determines whether the event indicates that the atomic 
transaction is complete (Figure 58B, block 765). If the atomic 
transaction is not complete ("N" exit to Figure 58B, decision 

20 block 765), control returns to block 762 to monitor events. If the 
atomic transaction is complete ("Y") exit to decision block 765), 
the transaction authority 700 determines that the transaction is 
finished (Figure 58B, block 774). 

If the incoming event is an error condition ("Y" exit to 

25 Figure 58B decision block 764), transaction authority 700 
processes the error event in the control superset 188Y (Figure 
58B, block 766). If the error is not critical (Figure 58B, decision 

236 



block 767, "N" exit), then control returns to block 762 to wait for 
the next event notification to arrive. 

If the error is critical (Figure 58B, decision block 767, "Y" 
exit), transaction authority 700 may call a critical error handing 
5 routine (Figure 58B, block 768). Critical error handling routine 
768 may attempt to resolve the error based on the rules within the 
control superset 1 88Y and/or on an inference engine 774 or other 
process control logic. Such an inference engine or other process 
control logic 774 may be programmed concerning the business 

1 0 model of the overall transaction so it has enough information to 
select appropriate actions based on error conditions. 

The process shown in Figure 58B can be nested. For 
example, the sub-transaction defined by one "participant" may 
itself be an atomic transaction based on the contributions of a 

1 5 number of participants — all of which are managed by the same or 
different transaction authority 700. 

Security Checkpoint Commerce Utility System 

A Commerce Utility System 90 can include service 
functions that enable it to perform as a "Security Checkpoint 
20 System 6000" (see Figure 58C) that provides security, archiving, 
and non-repudiation services that can certify and/or authenticate 
communicated information in certain ways. Security Checkpoint 
Systems 6000 can: 

• provide a distributed, highly efficient, and automated 
25 auditing and archiving layer for electronic commerce 

interactions, and 
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• enhance the depth of security of a distributed security 
environment such as VDE and the Distributed 
Commerce Utility layer. 
Thus, Security Checkpoint System 6000 may perform 
5 security and/or administrative functions. This Commerce Utility 
System capability takes the positive benefits of centralized 
security models (e.g., ability to have a central authority physically 
control the processing node) and deploys these capabilities into a 
distributed "user space" model that can achieve maximum 
1 0 efficiency and flexibility, support secure and manageable 
scalability (a principal weakness of centralized systems), and 
provide the enhanced security benefits of multiple, independent, 
secure environment layers. The latter capability is particularly 
adapted for highly sensitive communications desiring extra 
1 5 security assurance. These security layers are enabled by the 
required participation and security processing of one or more 
independent security checkpoint protected processing 
environments that reinforces the foundation distributed security 
environment. 

20 Information that passes through one or more Security 

Checkpoint Systems 6000 can be certified and/or authenticated to 
assure an information recipient (e.g., a party receiving information 
in a container) that certain communications functions and/or 
security steps (processes) occurred prior to receiving the 

25 information. This certification and/or authentication can include, 
for example, certifying or authenticating proper communication 
routing through required and/or authorized protected processing 
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Security Checkpoint Systems 6000. Such checkpoints may be, for 
example, distributed throughout a telecommunications network, 
and "local" to the physical and/or logical location of end-user 
VDE nodes (see Figure 58C). 
5 Security Checkpoint Systems 6000 may employ 

telecommunication switches adapted to certify and/or authenticate 
certain information and processes. For example, certificates 
issued by a Security Checkpoint System 6000 may certify that a 
required route was followed and that a required checkpoint 
1 0 examined a communicated secure electronic container, and/or that 
the sending of such a container or other electronic information was 
performed pursuant to certain stipulated rules and controls. For 
example, such a service can help ensure and/or certify and/or 
authenticate, that certain budgets, other limits, and/or restrictions 
1 5 are not exceeded, and/or certain other requirements are met. 

For example, a Security Checkpoint System 6000 may help 
ensure requirements (including that limits or other restrictions are 
not exceeded) for: the number of "shipped" information containers 
in a given period of time; the value of electronic currency 
20 contained within (or represented by) a given container and/or by 
containers over a certain period of time (very important to reduce 
improper electronic currency activities); the financial amount 
committed in a purchase order, including that proper ordering 
authority is present; and so on. Such requirement assessment may 
25 be in reference to, for example, container (or other digital 

information communication) activity communicated from a certain 
logical and/or physical area, node, node group, user or user 
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organization, and/or other user grouping, wherein said reference is 
determined through referencing secure node and/or individual user 
and/or organization and/or area identification information as, for 
example, a VDE secure container travels through said adapted one 
5 or more telecommunication switches. 

These Commerce Utility System "communications 
checkpoint" capabilities can provide useful security features by, 
for example, providing one or more "independent" distributed 
security "check points" along a telecommunication route that 

10 substantially increases security reliability by requiring the 
presence of a proper certificate and/or authentication securely 
provided by such checkpoint and securely associated with and/or 
inserted within said container by a process managed by said 
checkpoint (or a group of checkpoints). This presence can be 

1 5 tested by a receiving node — and a proper certificate or 
authentication can be required to be present, for example 
according to rules and controls, before such receiving node will 
process at least a portion of the content of one or more classes of 
received containers. Such container classes may include, for 

20 example, containers from specific individuals and/or groups 
and/or containers and/or container contents that have certain one 
or more specific attributes. 

Security Checkpoint Systems 6000 may be "independent" 
of end-user Virtual Distribution Environment nodes from a 

25 security perspective. Such nodes may, for example, be 

independent from a security perspective because they use key 
management to maintain multiple secure execution compartments 
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within their protected processing environments for checkpoint 
management, such that a security breach in end-user nodes shall 
not directly comprise the security of checkpoint operation, and to 
help ensure that a breach related to a secure execution 
5 compartment will not comprise other such compartments. 

Security Checkpoint Systems 6000 may also gather audit 
information including, for example, retrieving identity information 
of intended container recipients), class(es) of container 
information, checksum and/or other information employed for 

1 0 future validation (e.g., non-repudiation), and/or archiving of some 
or all portions of said container's content. Some of this 
information may be at least in part in encrypted such that one or 
more portions of such information may not be decrypted without 
the cooperation of one or more of the container sender, the 

1 5 intended and/or actual container recipients), and/or a government 
body having authority to access such information. 

Figures 58C and 58D show an example of a "checkpoint 
security" Commerce Utility System 6000 arrangement that 
provides communication checkpoint security, non-repudiation, 

20 and archiving services within the context of a telecommunications 
network connecting users 95(1), 95(2), 95(3). In this example, the 
security checkpoint systems 6000 may be part of the 
telecommunications infrastructure. For example security 
checkpoint systems 6000 may be part of one or more 

25 telecommunications switches or other equipment that has been 
designed to detect secure electronic containers 152 based, for 
example, on the header information they contain. 
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Security checkpoint systems 6000 in this example have the 
secure ability to control whether or not a secure container 1 52 
transmitted through the communications infrastructure will be 
permitted to pass - and the consequences of routing the container 
5 through the communications infrastructure. In one example, 
controls operating with a user 95(1 )*s protected processing 
environment may require certain kinds of containers 1 52 (e.g., 
containers that carry electronic currency) to include controls 404 
that require them to be routed through a security checkpoint 

1 0 systems 6000 (or a certain class of security checkpoint systems). 
Such controls 404 can prevent the container 1 52 or its content 
(e.g., currency it contains) from being used unless it is routed 
through the appropriate security checkpoint system 6000. 
For example, suppose that user 95( 1 ) wishes to send a 

1 5 secure container 1 52 to user 95(2). In this example, the user 95(1) 
transmits the container 1 52 to user 95(2) through the 
telecommunications infrastructure. That infrastructure may detect 
that the information being sent is a container, and may route the 
container for interception by the a security checkpoint system 

20 (system 6000(5), for example). 

Security checkpoint system 6000(5) may, after intercepting 
the container 152, examine the control information within the 
container to determine whether requirements for further 
communicating the container to user 95(2) have been satisfied. 

25 Security checkpoint system 6000(5) may forward the container to 
user 95(2) only if those requirements have been met - or it may 
modify the container to permit user 95(2) to open and use the 
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container subject to the container's controls 404 (which may limit 
use, for example). The security checkpoint system 6000 may be 
authorized to modify at least a portion of the container's controls 
404 - for example to add further use limitations. 
5 This Figure 58C example shows two "webs" of security 

checkpoint systems 6000. In this example, these "webs" represent 
collections of security checkpoint systems 6000 that have each 
been certified (by a Certifying Authority 500 for example) as 
being: 

10 (1) a security checkpoint system, and 

(2) a member of the particular class. 
Hence, in this example "web 1" represents the class of 
certified security checkpoint systems 6000(1 )- 6000(5), 6000(7); 
and Web 2 represents the class of security checkpoint systems 
1 5 6000(4)-6000(6). As one example, "web 1 " security checkpoint 
systems 6000 may be certified as being capable of handling 
containers containing electronic currency 6004. 

One of the requirements specified within the control 
information associated with the container 152 may be that it must 
20 pass through a "web 2" security checkpoint system (e.g., system 
6000(5)) - for example, to enable certain secure auditing functions 
such as trusted electronic currency tracking. A "web 1" security 
checkpoint system (e.g., system 6000(3)) may refuse to pass the 
container 152 to user 95(2) based on these controls 404 - or it may 
25 refuse to modify the container 152 to make it usable by user 95(2). 
By way of further example, suppose user 95(2) wishes to 
pass the container 152 along to another user 95(3). The controls 
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404 associated with the container 152 may require, in this 
particular example, that further communication of the container 
152 must be through a "web 1" security checkpoint system 
6000(7). This routing requirement may be been present in the 
5 controls 404 provided by user 95( 1 ), or it may be added by 

security checkpoint system 6000(5) or the user 95(2)'s protected 
processing environment. 

In the particular example shown, the controls 404 may 
enable the "web 1 " security checkpoint system 6000(7) to pass the 

1 0 container 1 52 along to user 95(3) via a further routing that does 
not include a security checkpoint system 6000 (e.g., via another 
type of commerce utility system and/or a non-secure 
telecommunications switch). 

Figure 58D shows an example process performed by an 

1 5 example security checkpoint system. In this example process, the 
security checkpoint system 6000 receives a container 1 52 (Figure 
58D, block 6002) and determines whether the requirements 
specified by its associated controls 404 have been satisfied (Figure 
58D, decision block 6004). If the requirements have been 

20 satisfied, the security checkpoint system 6000 may perform 

"requirements satis ified" consequences, e.g., modifying controls 
404 to satisfy the routing requirement mentioned above (Figure 
58D, block 6006). If the requirements are not satisfied (Figure 
58D, "N" exit to decision block 6004), the security checkpoint 

25 system may perform "requirements not satisfied" consequences 
(Figure 5 8D, block 6008). 
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Each set of consequences may involve some form of secure 
auditing, for example. If the security checkpoint 6000 passes a 
container 152 containing electronic currency for example, the 
security checkpoint 6000 may record one or more of the following 
5 auditing information: 

• sender identity, 

• sender node identity, 

• receiver identity, 

• receiver node identity, 

1 0 • certificate(s) on which the currency is based, 

• other security checkpoints 6000 the currency has passed 
through, 

• the identity of prior handlers of the currency, 

• date, time, and location of transmission, 
1 5 • date, time, and location of receipt, 

• how long the currency has been in transit, and 

• other secure auditing information. 

If the security checkpoint system 6000 refuses to pass 
and/or modify a container 152, it may produce an audit report 
20 including available tracking information, for example: 

• sender name, 

• nature of deficiency, 

• intended receiver, and 

• other tracking information. 

25 It may also notify the sender, the intended receiver, a government 
agency, or other authority. It may further charge a "failed 
communication" overhead fee to the sender, for example. 
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The security checkpoint system 6000 may then determine 
whether additional communications are required (Figure 58D, 
decision block 6010). If not, the process may complete. If 
additional communications are required ("Y" exit to decision 
5 block 601 0), the security checkpoint system 6000 may transmit 
the container 152 to the next system (Figure 58D, block 6012). 
The next system may be an additional security checkpoint system 
6000 that performs additional processing (Figure 58D, blocks 
6016, 6004, 6006, 6008). 

10 

EXAMPLES 

Example — Electronic Content Distribution Value Chain 

Figure 59 shows how example Distributed Commerce 
Utility 75 can be used to support an example electronic content 
1 5 distribution value chain 1 62. In the Figure 59 example, an author 
164 may create a valuable work, such as a novel, television 
program, musical composition, or the like. The author provides 
this work 166 (for example, in electronic digital form) to a 
publisher 168. 

20 The publisher may use his own branding, name recognition 

and marketing efforts to distribute the work to a consumer 95. 
The publisher 168 may also provide the work 166 to a content 
"aggregator" 170 - someone who provides customers access to a 
wide range of content from multiple sources. Examples of 

25 aggregators include, for example, traditional on-line information 
database services and World Wide Web sites that host content 



from many diverse sources. Typically, consumers use an 
aggregator's services by searching for information relevant to one 
or more consumer-defined topics. An aggregator 1 70 may provide 
the search tools to the consumer 95 who will make their own 
selections. 

The aggregator 1 70 might distribute the work 172 
containing some or all of the original work 166 directly to 
consumer 95. Aggregator 170 may also distribute the work 1 72 to 
a "repackager" 174. Repackager 174 may, for example, take 
content from several sources on related matters and combine them 
into mixed source products, such as multimedia combinations, 
newsletter publications, or "current awareness" packages. In these 
services, the repackager makes the selection of content and 
organizes based on audience-indicated interest. A consumer 95 
may subscribe to an electronic newsletter on a particular topic or 
the consumer may give the repackager 1 74 a short list of topics 
they are interested in. The repackager 174 will select relevant 
information and communicate the information to the customer. 
Here the repackager is doing the selecting for the consumer. 

For example, repackager 174 might be the publisher of a 
newsletter and might republish some or all of the author's work 
166 in this newsletter 176. Repackager 1 74 could directly 
distribute newsletter 176 to consumer 95, or the newsletter could 
pass through still additional channels. Repackager 174 could use a 
search engine provided by aggregator 1 70 to find articles of 
interest to consumer 95 and combine those articles into an 
electronic newsletter that has both the aggregator 170's brand and 
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the repackagers 174's brand, and then send the newsletter to the 
consumer 95. 

Distributed Commerce Utility 75 may support the Figure 59 
value chain in a number of ways. For example: 
5 1 . Certifying authority 500 can issue certificates that allow 

each of the value chain participants to identify who they are and to 
demonstrate that they are members of one or more particular 
classes. For example, author 164 and/or publisher 168 might 
specify that any certified aggregator or repackager is entitled to 

1 0 excerpt or anthologize work 166 so long as appropriate payment is 
made. Certifying authority 500 could issue digital certificates 504 
supporting this desired business objective, the certificates 
certifying that aggregator 170 is in fact a reputable aggregator and 
that repackager 174 in fact a reputable repackager. So long as 

1 5 author 1 64 and/or publisher 1 68 trust the security of the overall 
system 50 and the certificates 504 issued by certifying authority 
500, they will have no fear that the work 166 will be excerpted or 
anthologized by anyone other than the appropriate types of people 
they specify. 

20 In another example, certifying authority 500 could issue a 

certificate 504 to aggregator 170 or other user. Certifying 
authority 500 could issue this certificate 504 at the direction of 
author 164 or publisher 168. The certificate 504 may attest to the 
fact that author 1 64 or publisher 168 agree that aggregator 1 70 or 

25 other user is authorized to modify certain permissions 404. 

Author 164 or publisher 168 may have specified permissions 404 
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so that that will allow themselves to be modified only on the 
condition that an "authorized aggregator" certificate is present. 

In another example, certifying authority 500 could issue a 
certificate to one or more classes of users, enabling, for example, 
5 utilization of content and/or specific portions of content and/or 
modification of permissions, which such enabling may be limited 
to specific utilization and/or modification by employing certain 
VDE rules and controls put in place by the author or publisher or 
certificate authority (as allowed by in place rules and controls). 

1 0 2. Rights and permissions clearinghouse 400 in this 

particular example may be used to register work 1 66 and issue 
appropriate permissions 404 consistent with authorizations and 
instructions provided by each value chain participant. For 
example, the author 1 64 could register work 1 66 with rights and 

1 5 permissions clearinghouse 400, and specify an electronic control 
set 404 defining the rights of every other value chain participant. 
For example: 

• This control set 404 could specify, as one example, that 
publisher 168 can distribute an unlimited number of 

20 copies of the work 1 66 so long as the publisher pays the 

author 164 a certain dollar amount for each copy 
distributed. 

• The control set 404 might permit publisher 1 68 to add 
his own additional controls that allow consumer 95 to 

25 read the work 166 an unlimited number of times but 

prevents the consumer from copying or redistributing the 
work. 
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• Although the electronic control set may travel in an 
electronic container 152 with the work 166, it may also 
be provided separately. For example, rights and 
permissions clearinghouse 400 might, upon request, 
5 supply a control set associated with work 166 to anyone 

who requests a control set. 
Rights and permissions clearinghouse 400 might maintain 
different versions of the control set 404 for different user classes 
so that, for example, consumers 95 might receive one control set 
10 404a, aggregators 170 might receive another control set 404b, and 
repackagers 1 74 might receive a still further, different control set 
404c. Each of these control sets can be provided in advance by 
author 164 or other rights holders, providing a "pre-approved 
permissioning" system that makes widespread usage of work 166 
1 5 extremely efficient and yet highly secure, and further, such control 
sets may interact with VDE distributed template applications in a 
seamless manner — one or more template applications may be 
distributed with a control set by such distributors of such control 
sets (or may be otherwise made available) to such control set 
20 recipients. In one particular "superdistribution" business model, 
work 166 is allowed to be distributed as widely as possible, and 
rights and permissions clearinghouse 400 does the work of 
providing current control sets 404 authorizing particular value 
chain participants to use the work in particular ways under 
25 particular conditions. 

3. Usage clearinghouse 300 in this particular example may 
support the value chain by collecting usage information from each 
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value chain participant. The usage clearinghouse 300 may thus 
provide a secure auditing function, generating, for example, 
reports that track how many times the work 166 has been used and 
how it has been used. 
5 As one example, usage clearinghouse 300 might analyze 

usage information to determine how many consumers 95 have 
read the work. Usage clearinghouse 300 can, for example, report 
consumption information in varying amounts of detail and/or 
specific kinds of information, to various value chain participants 

1 0 consistent with privacy concerns and the accepted business rights 
of each party. As one example, the usage clearinghouse 300 might 
give consumer 95 a very detailed report about his or her own 
particular usage of work 166, while providing author 164 or 
publisher 168 with only summary report information that may, for 

1 5 example, not include the consumer name, address, or other direct, 
identifying information. 

As another example, reports could also flow directly from 
the repackager 174 to the aggregator 170, publisher 168 and 
author 164. Reports may be directed along any logical pathway, 

20 directly, or through any sequence of parties, and containing 

whatever mix of information for each party as is acceptable to the 
value chain and as may be enforced, for example, at least in part 
by VDE rules and controls 

4. Financial clearinghouse 200. in this example, may 

25 provide secure clearing of financial details of the transaction - 
ensuring that appropriate value chain participants compensate 
other appropriate value chain participants. As one example, 
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financial clearinghouse 200 may receive payments from consumer 
95 based on the consumer's use of work 166, and distribute parts 
of the payments appropriately to author 1 64, publisher 1 68, and 
other appropriate value chain participants in an automated, 
5 efficient process managed at least in part by VDE rules and 
controls. For example, financial clearinghouse 200 might 
interface with other banks or financial institutions to accomplish 
an automation of payment transfers, and/or it might assist in 
managing electronic money maintained within the overall value 

10 chain shown. Financial clearinghouse 200 may also assist in 

ensuring that itself and the other Commerce Utility Systems 90 are 
appropriately compensated for the administrative and support 
services they provide, that is, for example, secure VDE processes 
operating within Commerce Utility Systems 90 may automatically 

1 5 ensure the payment to such administrative and support service 
providers. 

5. Secure directory services 600. in this example, may 
support the example value chain by facilitating electronic 
communications between value chain participants and/or between 

20 Commerce Utility Systems 90. For example, secure directory 
services 600 can, upon request, provide electronic address and/or 
routing information allowing one value chain participant to 
electronically contact another. As one example, suppose a 
consumer 95 wants to obtain the latest addition of work 1 66 but 

25 discovers that the electronic address of publisher 1 68 has changed. 
Consumer 95 can electronically contact secure directory services 
600, which can provide current address information. Of course, in 
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commercial trading system applications, for example, secure 
directory services may provide much more elaborate services for 
the identification of desired parties, such as multi-dimensional 
searching of directory resources for identifying parties based on 
5 class attributes. Secure directory services 600 may also provide 
services that enable the identification of content, for example 
based upon content type and/or rules and controls associated with 
such content (pricing, allowed usage parameters such as 
redistribution rights, etc.). 

1 0 6. Transac tion authority 700 in this example might be used 

to assist repackager 174 in developing newsletter 176. For 
example, transaction authority 700 might help in automating a 
process in which a number of different works created by a number 
of different authors were all aggregated and excerpted for 

15 publication in the newsletter. Transaction authority 700 can 
securely maintain the current status of an overall multi-step 
process, specifying which steps have already been performed and 
which steps have yet to be performed. Transaction authority 700 
can also, for example, help arbitrate and mediate between different 

20 participants in such a multi-step process, and can in some cases 
actively influence or control the process (for example, by issuing 
new instructions or requirements based upon error or other 
conditions). 

Example — Manufacturing Chain 

25 Figure 60 shows an example manufacturing value chain 

supported by Distributed Commerce Utility 75. In this particular 
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example, a customer 95 places an order with a manufacturer 1 80 
and receives an order confirmation. The manufacturer may order 
parts and supplies from a number of different suppliers 182(1)- 
182(N). Suppliers 181(1)-182(N) may, in turn, order additional 

5 parts or sub-assemblies from additional suppliers 1 82(al ) A 

bank 184 may supply funds to suppliers 182 based on proofs of 
order and assurances that the manufacturer will pay back the 
advances. A transportation/warehousing company 1 86 may 
provide transportation and warehousing for supplies and/or final 
10 products. 

In this value chain, certifying authority 500 and transaction 
authority 700 can assist with secure flow of electronic orders, 
confirmations, terms and conditions, and contracts, and can also 
help to ensure that each value chain participant can maintain the 

1 5 desired degree of confidentiality while exchanging necessary 
information with other value chain participants. Usage 
clearinghouse 300 may assist in secure auditing of the overall 
process, tracking of physical and electronic parcels between the 
value chain participants, and other usage related operations. 

20 Financial clearinghouse 200 may handle the financial 

arrangements between the value chain participants, for example, 
assisting in coordinating between the world of electronic network 
1 50 and a paper-oriented or other world of bank 1 84. Rights and 
permissions clearinghouse 400 may provide a secure archive for 

25 electronic controls 404 defining parts or all of the transaction. 
Transaction authority 700 may securely monitor the overall 
progress of transactions occurring among value chain participants, 
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and provide periodic status reports as appropriate to each value 
chain participant. In addition, transaction authority 700 can assist 
in directing or arbitrating the overall transactions to ensure that all 
steps and requirements are fulfilled. Secure directory services 600 
5 can assist in routing information electronically between the 

different value chain participants. Of course, as previously stated 
for the present inventions and as applicable throughout this 
specification, VDE chain of handling and control and other 
capabilities, including rules and controls and secure 
1 0 communication techniques, would preferably be used as a 
foundation for the above activities. 



Examples of How Commerce Utility Systems Can Support One 
Another 

1 5 Figures 1 6A- 1 6E described above show how different 

Commerce Utility Systems 90 can support one another. In more 
detail, Figure 16A shows that a financial clearinghouse 200 may 
provide services to one or more other Commerce Utility Systems 
90, including, for example, the usage clearinghouse 300, the rights 

20 and permissions clearinghouse 400, the certifying authority 500, 
the secure directory services 600, the transaction authority 700 and 
another financial clearinghouse 200'. Under such circumstances, 
the plural Commerce Utility Systems constitute both a virtual 
clearinghouse and a higher order Commerce Utility System. 

25 In each instance, the financial clearinghouse 200 may 

collect funds due the support services and deposit these funds to at 

least one provider account employing at least one payment 
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method. The financial clearinghouse 200 may also provide VDE 
audit records confirming the source and amount of the funds and 
the provider account in which the funds were deposited by the 
financial clearinghouse 200. The financial clearinghouse 200 may 
5 provide assistance to one or more other support services in 

establishing provider accounts and communicating to such one or 
more support services the account number and/or numbers and 
terms and conditions that may apply. Both the support service 
request to the financial clearinghouse 200 and its responses to the 

1 0 requesting support service can be communicated in VDE secure 
containers (as mentioned earlier) to take advantage of their 
substantial security, confidentiality, flexible control architecture, 
and trustedness, and can be processed at each location by one or 
more VDE Protected Processing Environments. Financial and 

1 5 account information may be provided in the form of VDE control 
sets and/or be incorporated in VDE control sets by the financial 
clearinghouse 200 and/or by one or more other support services. 
Financial clearinghouses 200 may also provide services to each 
other to promote further operating and administrative efficiencies. 

20 For example, one financial clearinghouse 200 may provide 
services to its counterparts in other countries or in other 
geographic regions. In another example, one financial 
clearinghouse 200 may provide another financial clearinghouse 
200 access to one or more payment methods not directly supported 

25 by the second financial clearinghouse 200. 

Figure 16B shows that the usage clearinghouse 300 may 
also provide services to other Commerce Utility Systems 90. In 
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one example, the usage clearinghouse 300 may provide raw data, 
aggregated data, at least in part derived information, and/or reports 
to other electronic commerce support services such as financial 
clearinghouses 200, rights and permissions clearinghouses 400, 
5 certifying authorities 500, secure directory services 600, 

transaction authorities 700, and other usage clearinghouses 300'. 
These other infrastructure services may use this information as 
independent third party verification of certain transactions and 
their details, for market research on behalf of their own services, 
1 0 and/ or to resell this information, perhaps in conjunction with their 
own usage information. In one example, a rights and permissions 
clearinghouse 400 might sell reports to a publisher containing a 
combination of their own information, and that from the financial 
clearinghouse 200 and usage clearinghouse 300 plus secure 
1 5 directory service 600 and certifying authority 500. More 

specifically, a report might contain a list of objects registered at 
the rights and permissions clearinghouse 400 by a particular 
publisher, the number of requests to the rights and permissions 
clearinghouse for updated or additional rights and permissions, 
20 financial clearinghouse 200 summary revenue numbers for each 
digital property, the number of certificates by the certifying 
authority 50Q on behalf of the publisher indicating that the user 
had been certified and had a valid subscription to the publisher's 
digital works, and the number of requests to the secure directory 
25 service 600 seeking information about the network addresses of 
the publisher's online web servers. In each case, a support service 
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provided the information to the rights and permissions 
clearinghouse for incorporation in this report to the publisher. 



Example - Distributed Commerce Utility 75 Can Support 
Digital Property Purchasing. Licensing and/or Renting 
5 Transactions 

Distributed Commerce Utility 75 provides significant 
trustedness, security, convenience, and efficiencies for instances in 
which customers pay for digital information. Moreover, 
information creators and distributors can price this information — 

1 0 indeed, any digital property in any digital format — in various ways 
and in different ways in different markets. 

Figure 61 shows an example of an information delivery 
service arrangement 1000 in which an information provider 168 
provides electronic content for purchase, rental and/or licensing. 

1 5 In this example, an information services company 168 distributes 
information 166 to several global markets; including individuals, 
Their market areas include professionals, home office users, and 
the small office marketplace, as well as medium and large 
companies and consumers at home. For example, provider 168 

20 may deliver content 166 in electronic form to a home consumer 
95(1), a professional such as a lawyer 95(2), and to a corporation 
or other organization 95(3). In one example: 

• an individual consumer 95(1) buys under subscription 
pricing three articles 166(1) from an online 

25 encyclopedia; 

• a lawyer 95(2) buys three chapters 1 66(2) from a 

treatise on patent law; and 
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• two product marketing managers in a large company 
95(3) receive a proprietary market research report 
166(3). 

Prior to information delivery transactions, the consumer 
5 95( 1 ), professional 95(2) and company 95(3) may use a secure 
directory service 600 to locate the network address of the 
information provider 168 as well as assist in identifying the 
content they wish to work with. Subsequently, these parties 95 
may send an electronic message to provider 1 68 requesting the 
10 specific information they want to receive. Provider 168 may 
deliver this information 166 within VDE secure electronic 
containers 152 along with associated rules and controls 188 that 
control pricing and permissions. Each of parties 95 has an 
electronic appliance 100 including a protected processing 
1 5 environment 1 54 that enforces these controls 1 88. 

The provider 168 can price information differently for 
different markets. For example: 

• professionals 95(2) and SOHO (small office/home 
office) pay transaction fees; 

20 • large companies 95(3) pay a mixture of subscription 

and transaction fees (e.g., company 95(3) may pay 
$10 per page printed or excerpted from a larger 
report, and may also pay a subscription fee); and 

• Individual consumers 95(1) pay a flat subscription 
25 rate. 



259 



WOWIUMSI rCT/US!*/14Z62 

In each of these cases, local, state, and/or federal sales taxes, 
as appropriate, are included in the retail price. Payment methods 
may be provided within electronic control sets 188 delivered in 
electronic containers 152 with, and/or independently of, the 
5 associated content 166 (for example, as provided in Ginter, et al). 

A financial clearinghouse 200 ensures that provider 168 
receives payment through any authorized payment method. The 
information delivery service 168 accepts a broad range of payment 
methods. Some forms of payment are more popular in certain 
10 markets than in others. For example: 

• In the professional, SOHO, and consumer markets, 
credit (MasterCard and Visa) and charge (American 
Express) are popular. 

• Consumers 95( 1 ) also like credit cards, and are 
1 S making increasing use of bank debit cards. 

• Large companies 95(3) also use credit and charge 
cards, payment through Automated Clearinghouses 
(ACHs), and billing and payment through traditional 
and VDE secure Electronic Data Interchange (EDI) 

20 transactions based, for example, on X. 12 protocols. 

A financial clearinghouse 200 makes payment more 
efficient in several ways. For example, financial clearinghouse 
200 furnishes provider 168 with a convenient, "one stop shopping" 
interface to the several payment methods, and keeps track of the at 
25 least one account number associated with a given provider. 
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In this particular example, a certifying authority 500 may 
deliver digital certificates to each of consumers 95 specifying a 
consumer's one or more classes. For example, certifying authority 
500 may deliver: 

• one or more certificates 504( 1 ) attesting to the fact 
that consumer 95(1) is an individual consumer 
subscriber to information service 1000 and further 
attesting to the fact that the consumer is a registered 
college student and is a resident (for the taxation 
purposes related to the transaction) of California, 

• a certificate 504(2) attesting to the fact that 
professional 95(2) is a lawyer admitted before the bar 
of the State of California, and 

• one or more certificates 504(3) attesting to the fact 
that corporation 95(3) is a legally incorporated entity 
and has a certain credit worthiness. 

Control sets 188 may activate the different payment 
methods based on the presence of an appropriate digital certificate 
504. For example, control set 188(1) delivered to consumer 
electronic appliance 100(1) authorizes consumer 95(1) to use each 
of the three articles 166(1). Control set 188(1) may, for example, 
contain a requirement that the consumer 95(1 ) must have a 
certificate 504(1) from an independent certifying authority 500 (or 
from the information distributor or other party acting in a 
certifying authority capacity under authorization from a more 
senior certifying authority) attesting to the fact that the consumer 
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95(1) has a subscription that has not yet expired to the online 
encyclopedia. This certificate 504(1) may, for example, be used in 
conjunction with other certificates issued by the certifying 
authority 500 (e.g., perhaps run by, or authorized by, the US 
5 government or other governing body) attesting to the fact that the 
consumer 95(1) is a US citizen, resides within the US, and is a 
legal resident of the State of California. 

The Individual Consumer 

The consumer 95(1) pays the information provider 1 68 for 
1 0 the subscription through a transaction transmitted to the financial 
clearinghouse 200 in a VDE electronic container 1 52. The 
payment transaction may involve, for example, the consumer 
appliance 100 sending to financial clearinghouse 200 an electronic 
container 152(7) including rules and controls 188(4) and audit 
1 5 records 302( 1 ). The audit records 302( 1 ) may indicate, for 
example: 

• who should be paid, 

• the amount of the transaction, 

• the particular payment method (a VISA card, for 
20 example), 

• the subscriber's VISA card number and expiration 
date, 

• an identifier of the information subscription, and 

• the number of the provider's account to which the 
25 payment should be credited. 
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The secure container 152(7) may also contain rules and 
controls 1 88(4) indicating that municipal, California and US 
federal sales taxes should also be collected. The financial 
clearinghouse 200 collects the appropriate sales taxes and deposits 
5 the funds in the appropriate accounts, for example certain funds 
would be deposited in the account belonging to the appropriate 
State of California tax collection agency 1002. 

In exchange for the payment, the subscribing customer 
95(1) may receive from certifying authority 500 a certificate 
10 504( 1 ) indicating she is in fact a subscriber and the expiration date 
of the current subscription. 

The Professional 

The lawyer 95(2) in this example may be located in the 
United Kingdom. He purchases the three chapters 166(2) from a 

1 5 treatise on patents using a MasterCard, but pays in pounds sterling 
rather than in dollars. To perform the purchase transaction, the 
lawyer 95(2) may first be preauthorized by the financial 
clearinghouse 200 for purchases each month of up to $500 US (or 
the equivalent in pounds). The pre-authorization may be sent from 

20 the financial clearinghouse 200 to the lawyer's appliance 1 00(2) in 
the form of a budget control 188(5) in a secure container 152(8). 
The protected processing environment 154(2) within the lawyer's 
appliance 100(3) may open the container 152(8), authenticate the 
budget record 188(5), and store the control within an associated 

25 secure database maintained by PPE 154(2). 
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Upon receiving opening each of the three chapters 166(1 ), 
the lawyer's protected processing environment 154(2) may create 
an associated audit record, and may decrement available credit in 
the budget record by the amount of the purchase. At month end, 
5 or when the $500 preauthorized credit has been exhausted, the 
lawyer's PPE 154(2) may send to the financial clearinghouse 200, 
a secure container 152(9) with audit records 302(2) indicating all 
the purchases, their amounts, and the provider account or accounts 
to be credited, this supporting efficient automation of clearing 
1 0 processes. The financial clearinghouse 200 may open the secure 
container 1 52(9), debit the lawyer's credit card account, and pay 
the appropriate provider accounts their due. 

The Company 

Preliminary to content transactions, a distributed corporate 
1 5 financial clearinghouse 200A within the company 95(3), while 
operating under the authority of the financial clearinghouse 200, 
sends to each of managers 95(3 )A, 95(3 )B a secure container 152 
a budget record 188 indicating their currently approved monthly 
information and market research budget. A corporate distributed 
20 certifying authority 500A (in the same trust hierarchy as the 
certifying authority 500, in this example) may also issue digital 
certificates 504 (not shown) to employees of the company. 

In this example, each product manager 95(3 )A, 95(3)B 
prints selected portions of the report and the budget on his or her 
25 local appliance 1 00, which is decremented by $ 1 0 for each page 
printed. The protected processing environment 1 54(3) within the 
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local electronic appliance 100(3) securely performs this process, 
conditioning it on controls 188(3) that may require appropriate 
digital certificates 504(3) issued by certifying authority 500 and/or 
the distributed corporate certifying authority 500A. 
5 According to controls 1 88(3) supplied by the information 

provider, for example, at the end of the month, or when the budget 
for that month is exhausted, the corporation's appliance 100(3) 
sends to the corporate internal financial clearinghouse 200A audit 
records (not shown) indicating any purchases that might have been 

10 made during the reporting interval and the amounts and provider 
account numbers for those purchases. The distributed, local 
corporate financial clearinghouse 200A aggregates the sums in the 
audit records and sends in a secure container 152(12) at least one 
audit record 302(3) to the external financial clearinghouse 200 to 

1 5 authorize payment of the total amount owed the provider of the 
market research reports through an Automated Clearinghouse 
(ACH). Also in the secure container 152(1 1) (e.g., as part of audit 
record 302(3)) are the account number of the company 95(3) from 
which the funds should be debited and the account number of the 

20 market research company that issued the report into which the 
funds should be credited. The financial clearinghouse 200 
completes the payment process through the ACH and sends a VDE 
secure container (providing at least one audit record) back to the 
internal, corporate financial clearinghouse 200A as confirmation. 

25 Distributed clearinghouse 200A may, in turn, send, using a secure 
container (not shown), at least one confirming audit record to each 
of the product managers 95(3)A, 95(3)B. 
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Example: Distributed Commerce Utility 75 Can Supp ort 
Transactions Where A Consumer Purchases and Pays For A 
Tangible Item 

A significant portion of electronic commerce will entail the 
5 sale, purchase, distribution management, and/or payment for 
intangibles of all kinds. Commerce in tangibles has many of the 
same security, trustedness, and efficiency requirements as 
commerce in intangibles (e.g., digital information). For the 
computer to become a true commerce appliance, a distributed, 

1 0 secure, trusted rights/event management software layer (e.g., 
rights operating system or middleware) such as the Virtual 
Distribution Environment described in the Ginter et al. 
specification is a necessity. Thus, even when tangibles rather than 
digital properties are the object of secure electronic commerce, 

1 5 Distributed Commerce Utility 75 can play an important role. 

Figure 62 shows an example tangible goods purchasing and 
payment system 1010. In the Figure 62 example, imagine a well- 
known provider of clothing and certain related household items, 
for example, L.L. Bean or Lands' End, offers their wares over a 

20 digital network such as the Internet/World Wide Web. In this 
example, the company creates: 

• a Web catalog server 1 0 1 2 to offer a line of clothing 
to consumers 95, 

• a web fulfillment server 1014 that is an interface to 
25 the fulfillment function, and 

• a third web server 1016 that acts as a secure financial 
clearinghouse 200 and as an interface to several 
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payment methods (e.g., MasterCard ("MC"), VISA, 
and American Express ("AMEX"). 

The company also in this one example 

• registers the service with the secure directory service 
provider 600, and 

• through the financial clearinghouse 200, establishes a 
provider account with at least one payment method, 
such as a credit card, debit card, and/or bank, and 

• registers several transactions with a transaction 
authority 700. 

In this example, the company registers with the transaction 
authority 700, which may be a distributed transaction authority 
within the company selling the goods, an atomic transaction 
comprising at least one electronic control set that describes, for 
example: 

• sending the order to the fulfillment processing one or 
more organizations such as a warehouse 1018 and 
logistics 1020 (which may or may not be the same 
company), 

• receiving confirmation that the desired merchandise 
. is in fact in stock, 

• receiving confirmation of the order, 

• receiving payment pre-authorization from a payment 
method for the particular customer placing the order, 

• shipping instructions for the merchandise, 
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• confirmation that the merchandise was actually 
shipped, and 

• controls for completing the payment transaction. 

In this one example, the company also obtains at least one 
5 digital certificate 504 from a certifying authority 500 attesting to 
at least one fact, for example, that 

• the company is a legitimate corporation registered in 
the State of Delaware; 

• the company is not in bankruptcy and/or the company 
1 0 has a certain degree of creditworthiness, 

• the company has been assigned a particular Federal 
tax Identification Number, and 

• that the company has State tax Identification 
Numbers in each of several states, the specific states 

1 5 and their corresponding Identification Numbers, 

A customer 95 uses his or her electronic appliance 100 with 
Web browsing capabilities to access the catalog server 1012 over 
the Internet's World Wide Web. The catalog server 1012 sends 
the customer 95 a web page 1022 providing a page from an 

20 electronic catalog. Web page 1022 may be sent in one or more 
secure electronic containers 152(1). The customer 95 displays the 
web page 1022A using his or her electronic appliance 1 00, and 
clicks on the part of the web page showing a men's short sleeve 
Oxford button down shirt selling for $ 1 5 .95 . The current Web 

25 page is replace by a web page 1022B from the fulfillment server 
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1014. This second web page 1022B may be sent in a secure 
container 152(2). 

The customer's electronic appliance 100 has a protected 
processing environment 154. PPE 154 opens the secure container 
1 52, and displays the page 1022B on the screen. The page 1022B 
being displayed is a form that has several fields including the 
catalog number and description of the shirt and retail price. The 
customer 95 fills in fields for color, neck size, normal or tall 
person, normal or trim fit, and quantity. The customer 95 also 
indicates where the shirt(s) are to be delivered, the class of 
delivery service desired, and the customer's address. 

Upon the customer 95 completing the required information, 
the electronic appliance 100 puts the form field information 1024 
in a secure container 152(3) and sends the container back to the 
fulfillment service 1014. Fulfillment server 1014 opens the 
container 152(3) and reads the field information 1024. Fulfillment 
server 1014 creates a VDE audit record indicating receipt of 
information 1024. Fulfillment server 1014 may also create a 
control set 188 and/or an event notification that initiates a 
purchase transaction. 

Fulfillment server 1014 may communicate with warehouse 
1018 directly or through transaction authority 700. The 
fulfillment server 1014 then determines whether the required items 
are in stock and available to be shipped. If fulfillment server 1014 
determines that the required items are in stock and available to be 
shipped, and if the information 1024 provided by the consumer is 
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sufficient to proceed, the fulfillment service sends back to the 
consumer another Web page 1022C indicating: 

• that the purchase can be fulfilled, 

• what are the various sales taxes and delivery charges, 

5 • the address provided and class of delivery service 

chosen, 

• new fields for payment related information, and 

• a query asking whether the consumer wishes to 
proceed. 

10 The fulfillment service 1014 also sends audit records 302(1 ) 

to the consumer's PPE 1 54 and to the transaction authority 700 
indicating which parts of the larger, atomic transaction have been 
fulfilled. 

If the customer 95 determines he or she does not wish to 

1 5 continue with the transaction after viewing fulfil lment details,, his 

or her appliance 100 can send a secure VDE container 1 52(5) to 

the fulfillment service 1014 and to the transaction authority 700 

indicating that the transaction is canceled. If the customer 95 says 

yes, please continue with the transaction, the customer is 

20 prompted to pick a payment method from among the list provided. 

In this example, the list corresponds to payment methods 

supported by both the merchandise provider and by the financial 

clearinghouse 200. The customer 95 fills in credit or charge card 

number, for example, expiration date, and billing address. 

25 Upon completion of the required information, the 

customer's appliance 100 can send the information, using his or 

270 



her secure PPE, in a secure VDE container 152(5) to the financial 
clearinghouse 200, and may send a separate VDE container (not 
shown) with an audit record to the transaction authority 700. 

The financial clearinghouse 200 gets pre-authorization from 
the credit card processing company, and, for example, using a 
secure VDE container 152(6) returns the pre-authorization 
approval information 1026 to the fulfillment server 1014. 
Financial clearinghouse 200 may send another VDE container 
152(7) to the transaction authority 700 with an audit record 
302(2) indicating completion of the pre-authorization step. 

The fulfillment server 1014 may send a further VDE secure 
container 152(8) to the customer 95 with a new Web page 1022D 
and audit record information 302(3) indicating that: 

• the order process is complete, 

• the sale has been approved by payment method, 

• when the goods are shipped, the customer's credit 
card will be charged the total amount, and 

• a transaction confirmation number for further 
reference in order to be able to make inquiries with 
the fulfillment service 1014 and/or with the 
transaction authority 700 

The fulfillment service 1014 (e.g., in cooperation with 
warehouse 1018) packages the goods, hands them off to an 
express delivery service 1020, and, for example, sends VDE 
secure containers 152(9), 152(10) with audit records 302(4), 
302(5) indicating shipment to the financial clearinghouse 200 and 
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the transaction authority 700, respectively. In this example, the 
express delivery service ("logistics") 1020 also sends a VDE 
secure container 152(1 1) to the transaction authority 700 and to 
the fulfillment service (and also, if desired, to the customer 95) 
5 indicating that the express service 1020 has taken possession of 
the package. 

Upon delivery of the package with the merchandise, in this 
example, the express delivery service 1020 sends a VDE secure 
container 152(12) containing an audit record 302(7) indicating 

1 0 that delivery of the package has been completed to the transaction 
authority 700 which then marks the transaction completed and 
then may send additional VDE secure containers 152 indicating 
completion to the financial clearinghouse 200, to the express 
delivery service 1020, to the fulfillment service 1014, and in some 

1 5 examples to the customer 95. 

Example: Distributed Commerce Utility 75 Can Support 
Transactions In Which Customers Pav For Services 

A hallmark of advanced Western economies, especially the 

economy of the United States at the end of the present century, has 

been the transition from a largely manufacturing, "smoke stack" 

economy to not only an "information economy" but to a "service 

economy" as well. Distributed Commerce Utility 75 can support 

transactions in which customers pay for, and in many examples, 

consume or otherwise make use of services. 

Figure 63 shows an example online service system 1030. In 

one example, an online service 1032 registers with the secure 

directory service 600 and obtains a digital certificate 504(1) from 
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a certifying authority 500 attesting to identity of the online 
service. The online service also agrees to trust certificates 504 
issued by the certifying authority 500 and by parties certified by 
the certifying authority 500 to issue certificates for specified facts. 

5 

For example, the online service 1032 agrees to accept 
certificates 504(3) issued by a distributed certifying authority 
500A from parents certified by the certifying authority 500 
(through certificate 504(2)) to issue certificates attesting to the 

1 0 facts that they have children and that these children are currently 
minor children. In turn, the online service 1032 will not allow 
children so certified to access certain subject matter materials 
distributed by the online service nor to accept digital signatures 
based on those certificates for purchase transactions, unless the 

1 5 adult person responsible for the child has issued another certificate 
attesting to their willingness to be financially responsible (e.g., 
unconditionally or for purchases up to some specified limit per 
transaction or some aggregate level of spending in a specified time 
period, in one example, so much per month). These certificates 

20 504(2), 504(3) may be sent from the certifying authority 500 to the 
parent and/or to at least one child in a VDE secure container 152. 

. Now suppose the child 95(2) subscribes to an online game 
called "chat" Online service 1032 has a Web interface 
specifically designed for school aged children. This service 1 032 

25 offers a subscription that must be renewed quarterly. Using an 
electronic appliance 100 such as a personal computer or TV and 
settop box with bi-directional communications and a protected 
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processing environment 154, the child 95(2) uses secure directory 
services 600 to locate the online service 1032, and sends a 
message requesting a subscription. In response, the online service 
1032 sends to the parent 95(1) or guardian in a VDE secure 
5 . container 1 52(4), a request 1 034 for payment, membership, and 
member information. The parent or guardian and/or other paying 
individual 95(1) provides his or her (or their) credit card 
numbers), expiration date(s), and billing address information 
1036 in one or more other secure containers 152(5) to the online 

10 service 1032. 

In this example, the online service 1032 communicates the 
customer's service account, credit card and/or other payment 
information 1036 to the financial clearinghouse using a VDE 
secure container 152(6) (in a variation on this example, the parent 

15 95(1) may have provided this financial and related information 
directly to the financial clearinghouse 200 in a VDE secure 
container 152(5)). The online service provider 1032 also provides 
to the financial clearinghouse 200 the clearinghouse network 
address and provider account number. Within a protected 

20 processing environment (which may, for example, comprise a 
general purpose computer locked in a physically secure vault or 
other secure installation), the financial clearinghouse 200 opens 
the secure container 152(6), extracts the payment information 
1036, and completes the payment transaction with the credit card 

25 company. 

For this example, the financial clearinghouse 200, in turn, 
communicates the following information 1038 (this list is for 
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illustrative purposes only and does not detract from the general 
case in which any available set of information might have been 
communicated) to the online service 1032 in at least one secure 
VDE container 152(7): 

• VDE audit record for this transaction, 

• transaction authorization number, 

• provider account number, 

• account number of the customer at the service, and 

• amount of the payment. 

In turn, the online service 1032 sends a secure container 
1 52(8) to the customer 95(1) indicating that payment has been 
accepted. In one example, online service 1032 may instruct 
certifying authority 500 to issue a certificate 504 attesting to the 
validity of the subscription until a specified date. Online service 
1 032 may also provide audit records 302(1) derived from the 
information 1038 provided by the financial clearinghouse 200. 

Each time the child 95(2) logs on to the online information 
service 1032, the child's PPE 154 checks to determine if any 
certificates 504 are present or known and if so, whether: 

• these digital certificates attest to an current, unexpired 
subscription to the online service, and 

• any minor child certificates are present and valid (for 
example, have not expired because the child has not 
yet reached their 1 8* birthday). 
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Having ascertained through these certificates 504 that the 
child 95(2) is authorized to use the online service 1032 and is 
prohibited from accessing certain "adult" content, the online 
service grants selective access, that is to authorized portions. 
5 Among the features of this online service are distributed, 

multiperson interactive games. The child 95(2) in this example 
plays the game with at least one other authorized and certified 
minor child — adults are precluded by underlying VDE rules and 
controls from playing this game in this particular example. At 

10 least one portion of the software (e.g., executable code and/or 
interpretable code, such as Java) that implements at least one 
portion 1040 of the at least one game can be download from the 
online service 1032 to the child's information appliance 100(2) 
using at least one VDE secure container 152(9). 

1 5 Using methods described in the Ginter et al. disclosure, 

these programs and/or portions of programs 1 040 are determined 
to be authentic and unmodified. At least one of the keys used to 
calculate the one way hash function that produces the digital 
signature used for determining the integrity of the at least one 

20 program 1040 or at least one part of a program is bound to the 
identity of the online service 1032 by a certificate 504 issued by 
certifying authority 500. 

As the child 95(2) in this example plays the game, at least a 
portion of his or her activities are metered according to methods 

25 disclosed in the co-pending Ginter et al. application and audit 
records 302(2) are created that indicate this child's usage. At 
certain times, these audit records 302(2) are transmitted to the 
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online service 1032 which may, in this example, include a usage 
clearinghouse 300. Usage clearinghouse 300 analyzes these 
usage records 302(2), and may use them to determine how much 
to charge child 95(2). 

5 Example: D istributed Commerce Utility 75 Can Be Used tn 
Provide Value Chain Disaggregation for Purchase and/or f Js<» 
of Tangible Items 

Distributed Commerce Utility 75 can be used to facilitate a 
purchase or other type of transaction relating to tangible goods. 
0 Figure 64 shows an example tangible goods delivery system 1 040. 
For example, a company 1 042 places an order for office supplies * 
using an electronic appliance 100 including a PPE 154. The order - 
is for a box of paper clips, a stapler, staples, a case of 8.5 x 1 1 inch 
copy paper, and a dozen yellow legal size note pads. The items are 
5 manufactured by a manufacturer 1 050, distributed by a distributor 
1 048, and sold to the company by a retailer 1 046. 

In this example, a financial clearinghouse 200 receives a 
payment 1052 from the company 1042, and disaggregates the 
payment by dividing it up into disaggregated payments 1052A, 
1052B, 1052C which it delivers to each of retailer 1 046, 
distributor 1048 and manufacturer 1050. 

For example, the company 1042 sends its order 1044 within 
a VDE electronic container 152(1) to a retailer 1046. In this 
example, retailer 1046 provides a fulfillment service that receives 
the order 1044 and, in response, provides a control set 188 
indicating the provider account number of the distributor 1048 
and/or manufacturer 1050 of each item and the percent of the retail 
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price to be received by each. If desired, retailer 1 046 may provide 
a different control set 188 for each item ordered (regardless of 
quantity) - allowing different payment disaggregation to be 
performed on an item-by-item basis. Retailer 1046 may provide 
5 this control set 1 88a to company 1042. 

Control set 1 88a may be conditioned on the presence of one 
or more digital certificates 504 issued by certifying authority 500. 
For example, control set 188a may require company 1042 to 
provide a digital certificate 504(1) issued by the certifying 

1 0 authority 500. Certificate 504( 1 ) attests to the identity of the 
ordering company 1042. The company 504( 1 ) may provide 
another certificate 504(2) in the same chain of trust hierarchy as 
the certifying authority 500 warranting that the person placing the 
order is authorized to place orders up to a specified spending limit 

1 5 per order. Company 1 042 may provide the same or different 
certificate 504(2) also indicating that the purchaser employee 
within the company is authorized to make use of a corporate 
charge card. 

In this example, the company 1042 pays with a corporate 
20 charge card. The financial clearinghouse 200 first gets payment 
authorization from the credit card company prior to the retailer 
1046 shipping the merchandise. Upon receiving notification of 
preauthorization, retailer 1046 may ship the goods 1047 to the 
company 1042. Following delivery of the merchandise 1047, the 
25 retailer 1 046 creates at least one VDE audit and/or billing record 
1052 in at least one VDE secure container 152(2), and transmits 
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the container to the financial clearinghouse 200 (audit information 
may also or alternatively be sent to retailer 1046). 

The financial clearinghouse 200 then completes the charge 
card transaction by allocating the total payment amount to each of 
5 the value chain participants represented by control set 1 88a (which 
it may have received, for example, directly from retailer 1046 
and/or through company 1042). In this way, the distributors 1048 
and/or manufacturers 1050 receive their payments at the same 
time the retail seller 1046 receives its payment. Control set 

1 0 information 1 88a may also indicate shares of the total payment 

and provider account numbers for local, state, and federal taxes, if : 
any, and, for example, for delivery charges, such as to an 
overnight express company, if any. 

This Figure 64 example shows that value chain 

1 5 disaggregation can apply for both tangibles and for intangibles. 
Similar techniques can also be used much further back through the 
manufacturer's 1050 supply chains if so desired (e.g., to the 
providers of the metal from which the paper clips were fabricated). 

Example — Distributed Commerce Utility 75 Can Help 
20 Distribute Digital Properties Bv Providing Object Registry 
And Other Services 

Distributed Commerce Utility 75 can assist the electronic 
community in efficiently distributing electronic or digital 
properties or content For example, using an electronic appliance 
25 1 00 equipped with a protected processing unit 1 54, a creator or 
other rights holder 400 sends a digital object in a secure container 
to a rights and permissions clearinghouse 400 to be registered. 
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The rights and permissions clearinghouse 400 opens the 
container using, for example, its own VDE protecting processing 
unit, and assigns a uniform object identifier indicating the identity 
of the creator, the type of object being registered - software, video, 
5 sound, text, multimedia, etc., and the digital signature for the 
object. The uniform object identifier may be globally unique or 
may be unique only in the namespace domain of the creator or 
some other entity, such as an online service, digital library, or 
specific jurisdiction, such as a specific country. 

1 0 In this example, using its protected processing environment, 

the rights and permissions clearinghouse 400 digitally signs the 
uniform object identifier with the rights and permissions 
clearinghouse private key and returns the object and identifier to 
the person or organization registering it in a VDE secure 

1 5 container. The rights and permissions clearinghouse 400 may 
retain a copy of the object or may retain only the uniform object 
identifier for the object, and the signatures for the object and its 
uniform object identifier. In another example, the rights and 
permissions clearinghouse 400 digitally signs a new object 

20 comprised of the original object and its uniform file identifier, and 
stores both the new object and/or its signature in the rights and 
permissions clearinghouse 400 archive. 

The creator may have also sent in a VDE secure container a 
permissions and pricing template 450 (see Figures 45 A-45C) 

25 indicating which permissions are granted, the prices to be charged 
upon exercising those permissions, and if applicable, the 
individual, class and/or jurisdiction to which those prices and 
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permissions apply. More than one permission and pricing 
template 450 may be sent in a single VDE secure container 1 52, or 
separate VDE secure containers 152 may be used for each 
permission and pricing template. 
5 In this example, using a VDE secure container 1 52, the 

object is then transmitted from the creator to a distributor 168 (see 
Figure 16). Using a certificate 504, the distributor 168 can prove 
to the VDE instance (PPE 154) interpreting the creator's control 
set that the distributor is indeed authorized to selectively alter 

10 permissions and prices of the object and creates a new permissions 
and pricing template. The distributor 168 then sends a VDE secure 
container to the rights and permissions clearinghouse 400 
containing the uniform object identifier together with the new 
controls. In the preferred embodiment, if the object remains 

1 5 unmodified, the distributor 1 68 has the option of leaving the 
uniform object identifier unmodified; however, if the distributor 
has modified the object, perhaps to add its own brand, then the 
uniform object identifier must be modified to reflect the 
distributor's version. The digital signature is recomputed using the 

20 private key of the distributor. As before, the object registry has the 
option of storing only the digital signature or both the signature 
and the actual object. 

Example - Distributed Commerce Utility 75 Can Be Used to 
Facilitate Copyright Registration 

25 As a value added service, the rights and permissions 

clearinghouse 400 can provide a copyright registration service (see 

Figure 43). The rights and permissions clearinghouse 400 can send 
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a copy of the object to the appropriate online copyright 
registration service of the appropriate government agency 440, for 
example, the US Copyright Office, The object and uniform object 
identifier may be sent in a VDE secure container together with 
5 controls indicating the mode of payment, if a registration or 
processing is being charged. 

In this example, the copyright registration service can send 
at least one VDE secure container to the financial clearinghouse 
200 with at least one audit record indicating the amount to be paid, 

1 0 the payment method and account of the registering party, and the 
account of the government to receive the funds, and receives in 
return in a VDE secure container an audit record indicting that the 
transaction has been pre-authorized (or that for whatever reason, 
the proposed transaction has not been authorized). 

15 If the transaction has been pre-authorized by the financial 

clearinghouse 200, a VDE enabled computer located, in this one 
example, in US Copyright office opens the secure container and 
adds the uniform object identifier and the object to the registration 
database. Under a chain of trust emanating from the certifying 

20 authority 500 — which in this example may be operated by, or on 
behalf of the US government — the copyright registration service 
issues at least one digital certificate 504 attesting to the facts that 
an object with a specified uniform object identifier and with a 
specified digital signature has been in fact registered with the 

25 registration authority and that the at least one person is in fact the 
owner of the copyright at the time the object was registered. This 
certificate 504 is sent in a VDE secure container to the person who 



registered the object (and/or who was named as the person to be 
notified) and to the rights and permissions clearinghouse 400 who, 
in turn, may provide copyright registration information upon 
request in a secure VDE container. 

The copyright registration service sends at least one VDE 
secure container to the financial clearinghouse 200 with at least 
one audit record instructing the clearinghouse 200 to proceed with 
fulfillment of the pre-authorized transaction (if all necessary 
information was part of the pre-authorization process) and/or 
providing information to the clearinghouse 200 regarding, for 
example, the amount to be paid, the payment method and account 
of the registering party, the account of the US government to 
receive the funds, and that the payment transaction should be 
completed, and receives in return from the financial clearinghouse 
in a VDE secure container an audit record indicting that the 
transaction has been completed and funds deposited in the 
appropriate account or accounts, or that the payment transaction 
fail and the reason why it failed to be completed. 

Example - Distributed Commerce Utility 75 Can Supp ort 
Renewal Or Modification Of Permissions And Prices 

Distributed Commerce Utility 75 can further facilitate the 
distribution of electronic and digital properties by providing a 
mechanism for renewing rights and permissions that have expired. 
See Figure 42A. 

In one example, suppose an employee of a Fortune 1000 

company has a control set for a digital property, perhaps a piece of 

software or a Java applet, that has expired. The VDE protected 
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processing environment on the employee's computer can send a 
VDE secure container to the rights and permissions clearinghouse 
400. 

Distributed Commerce Utility 75 can also facilitate the 
5 distribution of electronic and digital properties by providing a 
mechanism for distributing rights, permissions and prices that 
have been changed by one or more participants in a distribution 
chain. In one example, suppose a customer has a digital object on 
her hard disk and its VDE control set as distributed by the 

10 publisher. The permissions and prices originally indicated a pay 
per use model in which the user pays 1 0 cents for each operation 
on the object, such as printing or viewing. 

To determine if new rights and prices are now available, the 
protected processing environment on the customer's PC can send a 

1 5 VDE secure container to the Rights and Permissions clearinghouse 
400 using its network address obtained from the control set 
together with MIME-compliant electronic mail. The customer 
obtained the address of the rights and permissions clearinghouse 
from the secure directory service 600, having, for example, sent a 

20 query in a VDE secure container and having received a response 
in a VDE secure container. 

The VDE secure container sent to the rights and permissions 
clearinghouse 400 contains the object identifier plus a request for 
the current controls including prices. The protected processing 

25 environment at the rights and permission clearinghouse 400 server 
opens the VDE secure container, retrieves the most recent control 
set from the database of controls, and sends via return electronic 
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mail another VDE secure container with the desired controls. The 
customer's protected processing environment opens this container, 
and replaces and/or augments the expired controls with the new 
ones. The customer is now able to use the content according to the 
rules and controls specified in the control set just received from 
the rights and permissions clearinghouse and processed by the 
instance of VDE on the local computer or other appliance. In this 
example, these new rules and controls have reduced the pay per 
use price from ten cents per operation to five cents per operation. 

Example - Distributed Commerce Utility 75 Can Supp ort 
Models To Distribute New Rights 

Distributed Commerce Utility 75 can also support 
transactions in which some or all rights are not initially distributed 
to the ultimate consumer with the content, but must be requested 
instead. In one example, suppose a lawyer decides to go into the 
publishing business by combining her/his own articles with other 
materials obtained from legal information distributors. The legal 
information distributors have chosen a rights and permissions 
clearinghouse 400 to be their distributor of control set information 
for their many properties. With each object they register at the 
rights and permissions clearinghouse 400 they also register two 
control sets in the formats described in the Ginter et al. disclosure: 

• one control set specifies default controls including 
prices for retail customer, and 
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• a second control set conveys rights and prices seldom 
of interest to the retail customer, for example, the 
anthologizing right. 

The attorney newsletter publisher obtains a chapter from a 
5 treatise on patent law and wants to include a 1000 word excerpt in 
the newsletter in addition to other articles. Having already 
obtained the treatise chapter and its retail control set, the 
newsletter publisher sends an inquiry in a VDE secure container 
using Internet MTME-compliant e-mail to the rights and 

1 0 permissions clearinghouse 400 asking for the excerpting right and 
the anthologizing right for the chapter identified by the enclosed 
uniform object identifier. The lawyer found the rights and 
permissions clearinghouse 400 using a secure directory service 
600 (alternatively the rights and permissions clearinghouse 400 

1 5 address may be contained in the original retail version received by 
the lawyer). 

The rights clearinghouse 400 checks the object database, 
locates the control set information for the object named in the 
universal object identifier, and determines that both the excerpting 

20 and anthologizing rights are available along with the prices for 
each. The excerpting right does not convey the right to modify the 
excerpted portion. The anthologizing right is conveyed along with 
controls that set the price to a 30% discount from retail prorated 
for the length of an excerpt if the whole chapter is not 

25 anthologized. 

Using a VDE aware page composition application, the 

newsletter publisher combines several works, including the 1000 
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word excerpt into a new work, and registers the new object with 
the rights and permissions clearinghouse together with its control 
set(s). The newsletter publisher also registers the new object with 
a copyright registration function, for example, the US Patent and 
Copyright Office. The newsletter publisher distributes the new 
work in a VDE secure container, which also contains control sets 
for each of the separate anthologized works, and for the whole, 
complete newsletter as well. The local VDE protected processing 
environment on the appliance of the user keeps track of usage 
according to the controls that apply to the composite object and to 
the controls of each of its parts for which there are separate rules. 
At some time, the VDE instance sends audit records to the usage 
clearinghouse 300 and to the financial clearinghouse 200. 

Example - Distributed Commerce Utility 75 Can Sup port 
Electronic Rights Negotiations 

Distributed Commerce Utility 75 can support electronic 
rights negotiations. In one example, suppose a professor is 
creating a "course pack": a compilation of many different works to 
be used by students in a particular course that in this example, 
lasts only one semester. In this example, the professor sends a 
VDE secure container with a query to the appropriate rights and 
permissions clearinghouse 400 and gets back control sets for the 
digital properties listed in the query. Upon reviewing the 
permissions and prices, the professor notes that a chapter from a 
book carries a price large enough to make the overall price of the 
course pack higher than the maximum s/he desires. 
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Using the negotiation mechanisms disclosed in Ginter et al. 
(see, for example, Figures 75A-76B), the professor attempts a 
negotiation with the rights and permission clearinghouse 400. The 
rights and permissions clearinghouse 400, in turn, automatically 
5 determines it lacks the authority to negotiate and redirects the 
negotiation to the publisher. 

Having obtained an appropriate certificate 504 from a 
certificate authority 500 by providing credentials indicating 
membership in the class "higher education", the protected 

1 0 processing environment of the publisher's Web server makes an 
offer of a new, modified control set for the property targeted for 
this professor. The controls have a discounted price, require that 
the copies be printed on a VDE enabled authorized printer that 
will keep track of the number of copies printed, and report back to 

1 5 the various parties to the transaction using VDE techniques. Still 
unhappy with the price, the professor sends a VDE negotiation 
counter-offer in a secure container to the publisher. The 
publisher's VDE instance negotiates with the professor's 
negotiation counter-offer control set and an agreement is reached 

20 that and provides a new control set with the new, agreed-upon 
prices and terms and conditions to the professor, who then goes 
ahead to produce the course pack. The rights and permissions 
clearinghouse 400 is willing to grant the reduced price in part 
because the professor in this example is able to provide a digital 

25 certificate attesting to the fact that she has a full-time appointment 
at the University of California, Los Angeles and has a certain, 
minimum number of students who will employ the materials. This 
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authentication meets requirements stated by the publisher to the 
rights and permissions clearinghouse 400. 

Example - Certification of Executables 

5 One valuable use of certifying authorities 500 is for the 

issuance of digital certificates on behalf of the government. In 
addition to issuing certificates attesting to identity, legal status, 
etc., government certifying authorities 500 might issue certificates 
certifying executables, for example load modules. For example, 

1 0 government certifying authorities 500 at all levels might certify 
the set of executables that represents the laws and trade practices 
of their administrative districts. For example, Saudi Arabia might 
insist that all appliances in their administrative control have load 
modules certified by the government that examine attributes of 

15 containers to insure that only appropriate content is released. The " 
State of California might certify a load module that calculates state 
tax, etc. 

Example - Entertainment Distribution 
20 Distributed Commerce Utility 75 can be used to efficiently 

and flexibly support models for film distribution to the consumer 
market For example, suppose that a film and entertainment 
company such as Disney wants to provide electronic Distributed 
Commerce Utility 75 to support distribution of its films to 
25 consumers 95. Disney could open a Commerce Utility System 90 
itself, or it might contract with a neutral third party to provide 
Commerce Utility Systems 90 on its behalf. The purpose of the 
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Commerce Utility Systems 90 in this example is to support secure 
pay-per-view/pay-per-use, rental, lease and other film distribution 
transactions to consumers. 

The films themselves could be distributed in digitized linear 
5 form — for example, on Digital Versatile Disk (DVDs) or other 
high capacity media. Such media would store, in addition to the 
films themselves, one or more secure containers including control 
sets for controlling use of the films. Consumers 95 could play the 
films using a media player 104 (see Figure 1) having a network 

10 150 connection or other "back channel" (e.g., the ability to read 
from and write to a smart card or the like). 

Media player 104 has a protected processing environment 
154 such as a secure processing unit for use in managing rights 
and manipulating the electronic containers. The storage media 

1 5 might also be played by a personal computer 124 equipped with a 
protected processing environment and a network connection. 

Set top box 104 may be controlled by electronic controls 
distributed on the media and/or via the back channel. The controls 
require the set top box 104 to record customer usage and payment 

20 information for each property the consumer decides to view. For 
example, a consumer 95 might place a media such as an optical 
DVD disk into media player 104 and hit the "play" button. The 
consumer's media player 104 might next display (e.g., on 
television set 102) a message telling the consumer how much it 

25 will cost to view that particular film (e.g., $2.95), and ask the 

consumer if she wants to proceed. If the consumer answers "yes", 
media player 104 will play the film on the consumer's television 
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set 102 — recording usage and payment information for reporting 
to Commerce Utility Systems 90. The protected processing 
environment 1 54 within media player 1 04 may, under secure 
control of one or more associated electronic control sets delivered 
.5 to it ~ monitor and collect information that can ultimately be used 
to ensure the consumer pays for watching the film and to provide a 
secure usage audit . The secure usage audit may be used, for 
example, to allow Disney, the film's actors and director, and 
others involved in making the film to securely verify how many 

1 0 consumers watched the film (and also potentially to provide 
demographic information for targeting advertising or the like). 
For example, the media player 104's protected processing 
environment may securely collect and record, for example, the 
following information within meter, billing and/or budget audit 

1 5 trails associated with particular controls: 

• name of film 

• digital identifier of film 

• time and date property played 

• number of times property played 
20 • who played the property. 

In one example, consumers 95 would have to possess a 
digital certificate 122 issued by an appropriate certifying authority 
that attests to certain facts. Such a digital certificate 122 can be 
used to provide a context for the electronic control set(s) delivered 
25 to media player 104. Such a certificate might need to be present 
before the consumer would be permitted to play the film and/or to 
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prevent the film from playing under certain conditions and/or to 
effect the controls that apply when the film is played. 

For example, the parents could obtain a digital certificate 
122 indicating that the household has children. This "child 
5 present" digital certificate 1 22 could be used to prevent media 
player 104 from playing any films other than those that have "G", 
"PG" ratings. Such certificates 122 could be issued by the same 
organization that provides the other administrative and support 
services in connection with this example if desired. 

1 0 The electronic controls provided with a particular film on a 

media such as an optical disk may also specify a particular value 
chain disaggregation to be applied in connection with payment 
arrangements. For example, the media player 104 would "know" 
from the electronic rules and controls delivered to it that the film 

1 5 distributor, studio and the Distributed Commerce Utility 75 are to 
receive particular percentages of the $2.95 usage fee, and that a 
state government authority must receive a certain tax payment in 
the form of a sales tax or VAT. Because this information is 
maintained within the protected processing environment 1 54 

20 within media player 1 04, the consumers 95 may never be exposed 
to the payment disaggregation scheme and/or its details. 
(Typically, consumers do not care what the distributor "cut" is as 
opposed to the studio revenue. The protected processing 
environment within media player 104 may provide this payment 

25 disaggregation locally or through a distributed or centralized 
financial clearing function 200 as described above.) 
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Media player 104 can report the usage containment 
information it has collected on a real time (online) and/or periodic 
event-driven basis. In one example, media player may report at 
the end of each month the information it has collected over the 
5 preceding month. It may report collected payment information 
(including disaggregation data provided by the control set) to a 
financial clearinghouse 200 run by Disney (or, for example, such 
information may be reported directly to clearinghouse 200). 
Financial clearinghouse 200 ensures that the consumer's account 

1 0 is appropriately debited and that the various payees (e.g., Disney, 
the film's distributor, and others in the value chain) receive 
appropriate "splits" of the consumer's payment. The financial 
clearinghouse 200 may also provide consumer credit checks and 
authorizations, helping to ensure that the consumer doesn't run up 

1 5 a big bill she can't pay. 

Media player 104 may report the usage information it has 
collected to a usage clearinghouse 300 operated by an independent 
auditor (the film's producer and actors may insist that an 
independent third party auditor - not Disney - performs this 

20 function) or, for example, may report such information to Disney 
and/or clearinghouse 200 — certain of such information may be 
concealed from Disney if required by rules and controls to ensure 
other value chain party rights and Disney may not be able to 
identify, alter, and/or remove such information due, for example, 

25 to VDE protection mechanisms. The usage clearinghouse 300 
may analyze the usage data and issue reports indicating total 
number of views, market share, etc. Usage clearinghouse 300 may 
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also further analyze the information to provide demographic 
and/or other marketing research information. This type of 
information can be very useful to advertisers and marketers. 
Disney may also operate a rights and permissions 
5 clearinghouse 400. Even though permissions are distributed on 
the optical media in this example, the rights and permissions 
clearinghouse can provide supplemental control sets for various 
reasons. For example, the control sets distributed on the media 
may expire on a certain date. Rights and permissions 

10 clearinghouse 400 may issue new control sets in lieu of the 

expired ones. Rights and permissions clearinghouse 400 may also 
issue permissions to provide "sales" and/or to otherwise change 
prices (e.g., to reduce the price of an older film). Rights and 
permissions clearinghouse 400 can also issue special permissions 

1 5 (e.g., an extracting or anthologizing right that multi-media 
developers or advertisers might be able to request, and/or, for 
example, redistribution rights to certain frames such as an 
approved image of Mickey Mouse for printing purposes). Disney 
could "pre-approve" some of these special permissions so that the 

20 rights and permissions clearinghouse could automatically provide 
them on demand. Digital certificates 122 might be used to interact 
with the permissions - thereby assuring that the user receiving the 
control set is entitled to take advantage of it. 

25 Example: Distributed Commerce Utility 75 Can Support The 
Collection. Analysis, and Repurposing Of Usage Information 
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Prior to the inventions disclosed in the Ginter et al. 
specification, the electronic community lacked general purpose, 
reusable, distributed, peer-to-peer technologies that could, among 
5 other things, efficiently and effectively monitor and measure 
usage on the local computer or protected processing environment. 
Collecting, analyzing, and reporting usage data provides 
significant value to rightsholders and to other distribution chain 
participants, to infrastructure Distributed Commerce Utility 75, to 
1 0 customers, and to other interested parties. Understanding what has 
happened can often be a fundamental determinant or contributor to 
what might or should happen. In addition, usage information can 
be repurposed to support a wide range of other commercial 
activities, including advertising and merchandising models. 

1 5 Suppose one or more customers in each of several 

companies have information appliances 1Q0, in this one example 
such as persona] computers, with VDE protected processing 
environments (PPEs) 154 as described in Ginter et al. Suppose 
further that over some time period, perhaps a month in this 

20 example, that VDE has been keeping track of detailed usage 

information and storing this information in the encrypted database 
on each hard drive on each computer that is a logical extension 
and under the control of each consumer PPE. These consumers 
have each been purchasing different combinations of information 

25 and entertainment from generally different sources. Each instance 
of VDE keeps track of usage information according to the controls 
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associated with the content and/or service being purchased or 
otherwise used. 

On or shortly after the first of each month, and/or any other 
required (or, if supported, allowed) reporting intervals, each 
5 instance of VDE communicates the usage records to the usage 
clearinghouse 300 according to the controls associated with each 
of the digital properties they have used during the previous month. 
In turn, the usage clearinghouse 300 provides reports to each of 
the rightsholders regarding any use of a property during the 

10 previous month or other reporting interval (e.g., daily, weekly, 
quarterly, annually, etc.). 

In one example these reports contain information 
identifying both the individual customer and the company that 
employees them. In another example, the reports contain detailed 

1 5 usage information, but the identities of the individual customers 
has been removed by the usage clearinghouse 300. Alternatively, 
both the individual and corporate identities may be removed. 
Instead, the usage information may be aggregated by any one or 
more certain classes, such as by industry, geography, and/or by 

20 country, and/or any other useful classes. 

In another useful example, a particular company or 
individual customer may have not permitted VDE (subject, of 
course, to this right being available through in place rules and 
controls) to communicate identity information to the usage 

25 clearinghouse 300 from their information appliances in the first 
place. The user may have established VDE controls prohibiting 
disclosure of such identifying information. In another example, the 
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user may have used the negotiation mechanisms disclosed in the 
Ginter et al. application to negotiate additional levels of privacy 
and confidentiality other than those required in the various control 
sets associated with the information being purchased or otherwise 
5 used by each customer, that is, the electronic negotiation process 
generates a modified or new rules and controls set reflecting the 
additional levels of privacy and confidentiality. In yet another 
example, a rightsholder, rights and permissions clearinghouse 400 
or usage clearinghouse 300 or other party, may have used the 
1 0 same negotiation mechanisms to negotiate, through the use of 
VDE rules and controls sets alternative levels of privacy and 
confidentiality. 

As illustrated in Figures 1 1 and 33-39, the usage 
clearinghouse functions that may remove identifying information, 
1 5 aggregate data, analyze data, generate reports, and/or transmit 
those reports to rightsholders and other interested parties may 
exist in one or more logical and physical locations. For example, a 
distributed usage clearinghouse 300 executing on the local 
computer (or other information appliance) may perform any or all 
20 of these usage clearinghouse functions. One or more usage 
clearinghouses may exist within a given company or within a 
given collection of companies comprising a vertical industry, 
healthcare, for example, trading group, or family of companies 
("keiretsu"). Similarly these usage clearinghouse functions may be 
25 performed by usage clearinghouses within each country or other 
jurisdiction or defined by any other class and/or geographic 
variable. 
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Usage clearinghouse 300 may also provide raw data, 
aggregated data, and/or customized reports to rightshoiders, 
distribution chain participants, and/or other interested parties. 
These parties include: for example, content creators, publishers, 
5 repackages, repurposers, advertising agencies and their clients, 
trade associations, market research and consulting companies, 
circulation audit and audience measurement bureaus, the sales, 
marketing, and advertising functions of companies with an interest 
in one or more markets, and government agencies. 
10 In another example the usage clearinghouse 300 may also 

sell information to advertisers indicating exposure to particular 
ads and/or classes of ads by individuals, customers within a 
company and/or group of companies, markets, and/or other 
analysis groupings and categories. 

15 Example: Secure Directory Services Protect Confidentiality 
and Privacy 

Personal and business confidentiality and privacy are often 
essential aspects of the modem experience. Individuals may not 
want others to know with whom they are associating. In many 

20 aspects of business, firms may not wish to reveal their interest in 
communicating or interacting or conducting business with other 
parties. In today's Internet, for example, it is possible for those 
with certain kinds of access to determine the nature of queries 
between a given person and a directory service. Such information 

25 may provide important clues regarding existing or pending 

business arrangements that have not yet been publicly announced, 

a merger or acquisition, for instance. 
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VDE secure containers provide one basis for secure 
directory services 600 in which confidentiality and privacy are 
preserved. In one example, the Corporation Counsel in a Fortune 
100 company wishes to obtain the email address of the investment 
5 banker in the firm handling a proposed acquisition — but without 
revealing her interest to anyone else. The attorney sends a query in 
a VDE secure container to the secure directory service 600 with 
the name and company of the person she wishes to contact. The 
secure directory service then sends the response in another VDE 
1 0 secure container back to the attorney. Both the query and the 
response can make use of certificates issued by the certifying 
authority 500 authenticating both the attorney and the secure 
directory service 600. Payment for the query can be handled by 
the financial clearinghouse 200 who deposits payment in the 
1 5 provider account of the secure directory service 600 while 

debiting the account of the company that employs the attorney. 

Because these transactions are conducted using VDE and 
VDE secure containers, those observing the communications leam 
no more than the fact that these parties are communicating. 
20 Security analysts have developed techniques for "traffic analysis", 
in which the frequency of communications among two or more 
parties is observed and changes in the frequency of 
communications are correlated with other information to make 
inferences regarding the content and/or purpose of these 
25 communications. 

Using VDE and VDE secure containers, it is possible to 
defeat traffic analysis, however at some added expense. In this one 
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example, the company could send a VDE container to the secure 
directory service 600 with an empty or "null" query that would 
generate in the average amount of elapsed time a return message 
in a VDE container with a null response. The instance of VDE on 
5 the attorney's computer would generate a payment transaction 
destined for the financial clearinghouse, but would aggregate these 
payment records with others to eliminate correlations between the 
pattern of queries and payments. While inefficient from a 
commerce standpoint, this method of using VDE and VDE secure 
10 containers to defeat traffic analysis attacks can in principle be used 
among plural parties wishing to hide the pattern of 
communications among them while taking advantages of the 
secure, trusted, efficient distributed transaction capabilities 
disclosed in the Ginter et al. application. 

15 Example: Cooperation Among Clearinghouses Internal and 
External To An Organization 

The various Commerce Utility Systems 90 may be 
distributed to varying degrees and in varying combinations as 
illustrated in Figures 2A-2E and 3A-3C). In one example shown in 

20 Figure 65, an American Fortune 1 00 company 1 070 with 

operations in several countries (e.g., the United States, Japan and 
Europe) and within many of those, in multiple locations within 
each country, has found it desirable to internationally distribute 
VDE Distributed Commerce Utility 75. To increase the efficiency 

25 of purchasing external information, and to maximize its leverage 

with information providers, the company 1070 has chosen to 

negotiate with several providers, agreements that treat all 
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purchases as having been made from within the US and being in 
US dollar currency. In this example, the company 1 070 maintains 
its own global Intranet 1072. Intranet 1072 connects company 
headquarters 1074HQ (shown here as being located within the 
United States) with company US employee electronic appliances 
1074US(1), ... 1074US(N), company Japanese employee 
electronic appliances 1074JP(1), 1074JP(N), and company 
European employee electronic appliances 1074EU(1), .... 
1074EU(N). Intranet 1 072 also permits each of these employees 
1 074 to communicate with one another. VDE-based transactions 
between the company 1070 and its information suppliers are also 
routed through one or another of the company ' s US gateways to 
the Internet. 

To provide efficient administrative and support services, the 
company 1070 has deployed in each country at least one 
distributed financial clearinghouse 200 and at least one distributed 
usage clearinghouse 300. For example, company 1070 may 
operate a financial clearinghouse 200A and a usage clearinghouse 
300A in the United States, a financial clearinghouse 200B and a 
usage clearinghouse 300B in Japan, and a financial clearinghouse 
200C and usage clearinghouse 300C in western Europe. In 
countries with multiple sites and within the United States, several 
of these distributed clearinghouses may exist. In addition to 
negotiating agreements with information providers, the company 
1070 may also have negotiated agreements with a large 
commercial usage clearinghouse 300 and with a major financial 
clearinghouse 200. These centralized clearinghouses could be 
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located anywhere, and may communicate with company 1070 via 
the Internet and the corporate Intranet 1072. Neither of these 
clearinghouses 200, 300 are affiliated with the company 1070 
other than through this business arrangement. Each of the 
5 distributed clearinghouses within the company 1 070 operates 
under the simultaneous authority of both the company and the 
external clearinghouses with which the company has a business 
arrangement. 

In this one example, a product marketing manager 

1 0 1 074JP( 1 ) employed by this company 1 070 in Japan acquires a 
market research report 166 from an American distributor 1076. 
The report and associated controls are sent from the American 
distributor 1076 to this employee 1074JP(1) in a VDE secure 
container 152a. The instance of VDE on the manager's appliance 

1 5 1 074JP( 1 ) keeps track of usage and the payment due the 

information provider. Periodically, these audit records 302(1), 
302(2) are transmitted in VDE secure containers 1052b, 1052c to 
distributed usage clearinghouse (private usage clearinghouse) 
300B and to the internal financial clearinghouse 200B - both of 

20 which are located in Japan on the company's internal, private 
corporate network (or Intranet) 1072. From time to time and in 
accordance with VDE controls associated with the content 
purchased, the private usage clearinghouse 300B removes, in this 
example, individual identifying information in accordance with 

25 VDE rules and controls managing protected processing 

environment processes and sends in a VDE secure container the 
audit records 302(3) to the external, commercial usage 



clearinghouse 300. All of the company's internal, distributed 
usage clearinghouses 300A, 300B, 300C send periodic 
communications in VDE secure containers 1 52 to the commercial 
usage clearinghouse 300. In turn, the master usage clearinghouse 
300 creates and sells, licenses, and/or otherwise distributes reports 
to rightsholders and other parties (e.g., third parties having a 
commercial interest in obtaining the information) in which the 
identities of individuals are removed, and which in many 
circumstances company names, in accordance with VDE rules and 
control, have also been removed. 

From time to time and in accordance with VDE controls 
1 88a associated with the content 1 66 purchased, copies of the 7 
complete usage records (with employee identification information) 
are also sent to the company's master usage clearinghouse 300HQ . 
(which may be located at corporate headquarters), as are audit 
records from all the company's distributed usage clearinghouses 
300A, 300B, 300C. These are then aggregated and combined for 
further analysis, reporting, and auditing. 

The internal, distributed financial clearinghouses 200A, 
200B, 200C also receive audit records 302 in VDE secure 
containers 152 in accordance with VDE controls sets for the 
purchased information from each of the VDE protected processing 
environments 1074 reporting to them. Each internal financial 
clearinghouse 200A, 200B, 200C aggregates the payments and 
from time to time sends a VDE secure container 1 52 with audit 
records 302 indicating the aggregate sums to be transferred to the 
information providers as a result of transactions. The company 

303 



may also provide update information regarding the accounts from 
which the company's funds are to be transferred and/or the 
provider accounts that are to receive such funds. In turn, the 
external master financial clearinghouse 200 completes these 
5 payment transactions and sends audit records back to the company 
1070 and to the information providers confirming the payment 
transactions. In the preferred embodiment, these activities occur 
securely under the control of distributed VDE nodes, and are 
automated at least in part through the use of VDE containers and 

1 0 chain of handling and control managing multi-nodal, multi-party, 
sequence of processes. As an alternative example, the calculation 
for the amount of payment and the completion of the payment 
transactions is performed at the external master financial 
clearinghouse 200 from usage information received from the 

15 usage clearinghouse 300 (of course, if usage clearinghouse 300 
and financial clearinghouse 200 are the same party, the financial 
clearinghouse already has received such information). The 
external and internal financial might then, in this example, 
compare payment information. 

20 This example does not depend on the extent to which 

administrative and support services are distributed. In a related 
example, the usage and financial clearinghouse functions could 
have been distributed to each VDE-aware protected processing 
environment 1074 as illustrated in Figures 2A-2E and 3A-3C. In 

25 this example, each protected processing environment 1074 could 
report directly to the master external clearinghouses 200, 300, to 
distributed external clearinghouses, and/or to internal 
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clearinghouse functions organized differently than described just 
above, for example, by continent (North America, South and 
Central America, Australia, Europe, etc.) rather than by country 
and company 1070 location. 

In one further example, the corporate headquarters 1 074HQ 
and its associated headquarters-based clearinghouses 200HQ, 
300HQ provide a centralized clearinghouse system through which 
all usage and financial information must flow. In this particular, 
more centralized example, all user appliances 1074 report their 
usage and financial transactions to headquarters-based 
clearinghouses 200HQ, 300HQ in secure containers 1 52 over 
Intranet 1072. Company headquarters financial clearinghouse r 
200HQ may interface directly into VDE compliant general 
purpose payment systems that directly support the use of VDE 
chain of handling and control for ensuring the enforcement of 
automated, secure, financial transaction fulfillment in accordance 
with rules and controls governing payment related variables such 
as payment amounts, parties, locations, timing and/or other 
conditions. These headquarters-based clearinghouses 200HQ, 
300HQ, (which may function as a single, integrated Commerce 
Utility System) in turn, may communicate appropriate aggregated 
and/or other audit trail and/or payment information to the 
individual clearinghouses 200A, 200B, 200C, 300A, 300B, 300C 
within each country. While less efficient than the less hierarchical 
example described above, this arrangement may appeal to large 
corporations who wish to exert centralized control over usage and 
financial information by acting as the central administrator for the 
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provision of credit and/or electronic currency to distributed 
internal financial clearinghouses and by efficiently managing in- 
house collection of transaction related information. 

Example: Tra nsaction Authorities Can Be Used Within and 
5 Between Organizations 

Figure 66 shows an example use of transaction authority 
700 for inter and intra organizational communications. Figure 66 
shows an organization A (left-hand side of the drawing) as having 
an "Intranet" (a private data network within a particular 

1 0 organization) 5 1 00(A). Intranet 5 1 00(A) may be a local and/or 
wide area network for example. User electronic appliances 

100(A)(1) 100(A)(N) (for example, employees of organization 

A) may communicate with one another over Intranet 5 100(A). 
Figure 66 also shows another organization B that may have 

1 5 its own Intranet 5 1 00(B), user electronic appliances 1 00(B)( 1 ), 
100(B)(N), and private transaction authority 700(B). In addition, 
Figure 66 shows a public data network 5 104 (such as the Internet 
for example) and a public transaction authority 700(C). Figure 66 
shows that in this example, organizations A and B communicate 

20 with the outside world through trusted transaction authority 

700(A), 700(B) (which may, if desired, also include "gateways", 
"firewalls" and other associated secure communications 
components). In other examples, trusted transaction authority 
700(A), 700(B) need not be the actual "gateway" and "firewall" 

25 to/from Internet 5 1 04, but could instead operate wholly internally 

to the respective organizations A, B while potentially generating 

electronic containers 302 for transmission over Internet 5 1 04. 
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In this example, organization A user protected processing 
environments 100(A)(1), 100(A)(N) each have an instance of a 
virtual distribution environment protected processing 
environment, and can communicate with one another over Intranet 
5 100(A) via secure electronic containers 302. Similarly, 
organization A user electronic appliances 100(B)(1), 100(B)(N) 
each have an instance of a virtual distribution environment 
protected processing environment, and can communicate with one 
another over Intranet 5100(B) via secure electronic containers 302. 
In addition, organization A and organization B can communicate 
with one another over Internet 5 1 04 via secure electronic 
containers 302. 

Organization A's private trusted transaction authority 
700(A) may be used for facilitating organization A's internal 
communications and processes. Private trusted transaction 
authority 700(A) might be used, for example, to carefully track 
items sent from one user to another within organization A. The 
public transaction authority 700(C), meanwhile, can be used to 
coordinate between organization A and organization B without, 
for example, revealing confidential information of either 
organization to the other organization. Below are more detailed 
examples of how the Figure 66 arrangement might be 
advantageously used to conduct business transactions. 

Suppose a confidential memo needs to be approved by users 
100(AX1), 100(A)(3) and 100(A)(5) (who can each revise the 
memo) before being distributed to each of users 1 00(A)(2), 
100(AX7)-100(A)(10) and 100(A)(12) (none of whom can change 
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the memo), with copies to users 100(A)(1), 100(A)(3) and 
100(A)(5) (who also can't change the memo after all three of them 
have signed off on it) and to no one else. Private transaction 
authority 700(A) can maintain a rule set that specifies these 
requirements. Transaction authority 700(A) can: 

• send the memo (in secure containers) in "round robin" 
fashion to each of users 100(A)(1), 100(A)(3) and 

1 00(A)(5) for approval. 

• If any one of these users changes the memo, then 
transaction authority 700(A) can circulate the revised memo 
to the other two for additional comments and revisions. 

• Once all three of users 100(A)(1), 100(A)(3) and 100(A)(5) 
approve the memo, transaction authority 700(A) may be 
empowered to place each of their digital and/or handwritten 
signatures or initials on the memo, place it into one or more 
secure containers with a control set specifying it is read 
only and can only be read by users 1 00( A)( 1 y 1 00(A)(3), 
100(A)(5), 100(A)(7)-100(A)(10) and 100(A)(12). 

• Transaction authority 700(A) may then send a copy of the 
memo in a container to each of these users, or could require 
the same container to circulate from one to another. 

• The transaction authority 700 may require the electronic 
controls to maintain a secure audit trail indicating where the 
container has been, who has opened it, who has accessed the 
memo it contains, and when. Transaction authority 700(A) 
might thus increase personal accountability by evidencing 
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whether a particular person had seen a particular document, 
when, and for how long. 

Organization A's Intranet 5 104 might also be used to 
exchange and/or distribute highly confidential design 
5 specifications. Transaction authority 700(A) can, for example, 
maintain, in digital form, a detailed record of who has "signed off 
on the design specifications - thus ensuring personal 
accountability and providing a high degree of efficiency. 

As mentioned above, private transaction authorities 700(A), 
1 0 700(B) can also provide a "firewall" function to protect 

confidential information from escaping to outside of the respective 
organizations A, B. Suppose for example that organization A is an. 
integrated circuit design house and organization B is an integrated 
circuit foundry. Organization A designs and specifies the circuit 
1 5 layout of a chip, producing a "tape out" that it sends to 

organization B. Organization B manufactures an integrated circuit 
based on the "tape out", and delivers chips to organization A. 

Transaction authority 700 can be used to facilitate the above 
business transaction while protecting confidentiality within each 
20 of organizations A and B. For example: 

• organization A's private transaction authority 700(A) can 
supervise an overall design and specification development 
effort within organization A. All communications take 
place in secure containers 302 over organization A's 
25 Intranet 5 100(A) to maintain confidentiality. Transaction 

authority 700(A) can maintain a secure archive of historical 
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design documents, works in progress, and specification 
versions as the design process progresses. 
Organization A's private transaction authority 700(A) can 
manage the final design specification development ~ 
ensuring that all conditions required to finalize the design 
specifications are followed. 

Once the design specification has been finalized, transaction 
authority 700(A) can circulate it within secure containers 
152 to those individuals within organization A that need to 
"sign off' on it. Their respective appliances 100(A)(1), ... 
1 00(A)(k) can affix and/or embed digital signatures, 
handwritten signatures, seals and/or fingerprints as 
described above to indicate specification approval. 
Upon being satisfied that the specification has been "signed 
off" by the appropriate people, transaction authority 700(A) 
can send it over Internet 1 104 within a secure container 302 
to public transaction authority 700(C). Public transaction 
authority 700(C) may be a commercial transaction authority 
retained by organizations A and B to act as a liaison 
between them. Organization A's private transaction 
authority 700(A) can filter (or protect) all information it 
sends to public transaction authority 700(C) to ensure that 
organization B can access only that information intended for 
it. For example, private transaction authority 700(A) might 
provide additional electronic controls within the container 
to prevent organization B from seeing any detailed audit 
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information showing where the specification has been 
within organization A. 

• The public transaction authority 700(C) might act as an 
independent trusted third party, notarizing and/or certifying 
the design specification to later evidence that organization 
A delivered it on a particular date and time in accordance 
with a contract. 

• Public transaction authority 700(C) could then forward the 
design specification (still within a secure container) over 
Internet 5104 to organization B's private transaction 
authority 700(B). 

• Organization B's private transaction authority 700(B) could 
automatically send a copy of the design specification over 
organization B's Intranet 5100(B) to the appropriate users 
100(B)(1), 100(B),(N) within organization B. No one 
outside of organization B would need to know who received 
a copy of the specification. On the other hand, organization 
A's transaction authority 700(A) could, if desired, include 
electronic controls restricting access to only certain 
engineers within organization B - and these secure controls 
would be carried along into organization B and securely 
enforced by electronic appliances 100(B)(1),..., 100(B)(N). 
Organization B's transaction authority 700(B) could 

manage the chip manufacturing process, ensuring that all steps and 
conditions required to manufacture chips in accordance with 
organization A's design specification are followed. 
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Example - Transaction Authority Can Facilitate International 
Commerce 

Figure 67 shows an example of how transaction authority 
700 can be used to conduct international commerce. In this 
5 particular example, a transaction authority 700 coordinates a 
complex multi-national transaction between companies 1 106 A, 
1 106B and 1 106C located in their own respective countries (e.g., 
the United States, Australia and Europe). Company 1 1 06A has its 
own bank. 1 108A and lawyers 1 1 10A. Similarly, company 1 106B 

1 0 has its own bank 1 1 08B and lawyers 1 1 1 0B, and company 1 1 06C 
has its own bank 1 108C and lawyers 1 1 IOC. 

The transaction authority 700 may assist in forming 
agreements between the international parties, by for example 
passing offers and counteroffers back and forth in secure 

1 5 containers and using the contract forming techniques described 
above to establish some or all of the terms and provide non- 
repudiation. Once a contract is formed, transaction authority 700 
may maintain a master set of rules and controls specifying all the 
conditions that must be satisfied to complete the transaction - and 

20 may thus provide consequences for different events. Alternatively, 
once the contract is executed, the transaction authority role may be 
virtual, particularly in simpler models, that is the value chain rules 
and controls can be carried by VDE containers whose rules and 
controls may, as a whole, specify all processes and conditions that 

25 must fulfilled, including their sequence of operation. Rules and 
controls provided by a transaction authority 700 may take 
international law into account — with differing rules applying to 
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different countries. The rules could take into account various 
import and export requirements and restrictions, international tax 
treaties between nations, contain upfront and/or ongoing customs 
related routing and filing requirements, identify reputable currency 

5 transaction authorities, assist in filing contracts or certain contract 
terms with relevant national and international authorities, manage 
any shipping or other transportation requirements, assist in 
establishing conclusive translation services for contract terms 
(particularly standard terms and conditions), manage differences 

0 in international certifying authority requirements and formats, 
impose societal regulations required by applicable governing 
bodies, and collect applicable governing body taxes, such as taxes ' 
for both national and regional governing entities, etc. Transaction 
authority 700 may communicate between the various international 

5 parties using secure electronic containers, and may securely 

validate and authentic various event notifications provided by the 
international parties. 

Example: Distributed Transaction Authorities 

[) Complex business interactions under the control of a 

transaction authority 700 may also be distributed within and 
among, for example, organizations and/or jurisdictions. Suppose a 
complex international real estate transaction requires participation 
of several functions within the purchasing and selling companies, 

5 several financial institutions, insurance companies, and law firms, 
and perhaps government agencies in a few countries. Suppose 
further that each of the organizational and individual parties to the 
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transaction has computers that are VDE-aware, and that within 
each organization or agency there is at least one distributed 
transaction authority that performs services for this real estate 
transaction under an authority granted by a master transaction 
5 authority 700. 

In this one example, each of the parties to the real estate 
transaction has contributed commerce rules and parameters 
representing their business relationships in the form of VDE rules 
and controls that define each parties role in the overall transaction. 

10 For instance, the insurance company must insure the property at a 
value and cost that the purchaser finds acceptable and that is also 
approved by the mortgage lenders). Also, suppose that these 
transaction VDE rules and controls have already been mutually 
agreed upon using negotiation mechanisms described in the Ginter 

1 5 et al. application, and that the negotiated rules and controls 
together with the history of negotiating these rules and controls 
have all been stored at the master transaction authority for this real 
estate transaction. The most senior transaction authority may be a 
master transaction authority 700 or might be any mutually agreed 

20 upon distributed transaction authority. In this one example we 
assume the former. In short, in short, all parties have agreed to the 
rules and controls that govern the transaction. The negotiation 
process may have been simplified because the transaction 
authority 700 may have distributed a distributed template 

25 application for international real estate sales, the template being 
based on the transaction authority 700' s past experience or that 
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were created by the transaction authority 700 especially for this 
transaction as a value added service to its important customers. 

Each of the parties to the transaction is, according to the 
VDE control sets that define this atomic transaction, responsible 
for seeing that certain pieces of the transaction are completed prior 
to the closing and consummation of the overall transaction. In 
some cases, plural parties are jointly responsible for completing 
part of the over all transaction. For example, the buyer and seller 
must have agreed on a purchase price. In this example, they 
contribute their business requirements, including, for example, 
their price and other variables, and they use the VDE negotiation 
mechanisms to arrive at an agreement that represents a fair balance 
of interests. If the electronic negotiation is unsuccessful, the 
parties may directly negotiate, or VDE secure containers with 
audit records indicating failure are sent to the transaction authority 
who, in turn, notifies each of the other parties authorized to 
participate in the overall transaction. 

If the buying and selling parties do agree, in this one 
example, notification is sent by the VDE protected processing 
environment that completes the negotiation (or receives 
negotiation completion instructions digitally signed by both 
parties through the use of VDE techniques) to a distributed 
transaction authority, which in turn, notifies other parties, 
including other participating transaction authorities, that price has 
been agreed upon. Based on VDE controls for subtransactions, 
VDE may securely notify a party or parties that certain other 
subtransactions are now to be completed. In this example, the title 
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search company may now perform their task; an insurance 
company may now begin negotiations with the buyer for coverage 
using the VDE negotiation mechanisms. An attorney in the 
Counsel's office for the purchaser may begin negotiations with his 
5 counterpart in the seller's company; both in-house attorneys may 
interact with their outside counsel using VDE and VDE secure 
containers in creating and negotiating the various documents 
whose execution completes parts or the overall transaction. 

In this example, each of the parties may have one or more 

1 0 digital certificates issued by the certifying authority 500 to 
authenticate each of the parties to this transaction and its 
subtransactions. The financial clearinghouse 200 provides a 
payment vehicle for various value added services, in one example, 
those provided by the transaction authority 700. The usage 

1 5 clearinghouse 300 collects audit records sent from time to time in 
VDE secure containers from each of the participating VDE 
protected processing environments and provides an independent 
third party audit of these transactions. The secure directory 
services 600 helps participants locate each other's electronic 

20 addresses while maintaining confidentiality and privacy. 

As each of the subtransactions is completed, a distributed 
transaction authority within the organization within which the 
subtransaction is completed notifies the master authority for this 
transaction 700 of completion of that subtask. According to the 

25 previously agreed upon VDE rules and controls sets, some or all 
of the persons participating in the transaction may also be notified 
by audit records and/or messages that are securely sent from, and 
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authenticated by, at least one participating VDE protected 
processing environment, including, for example, PPEs at nodes for 
individuals, distributed Commerce Utility Systems, a distributed 
transaction authority, and/or the master authority for this 
5 transaction. 

When all the component elements of the overall transaction 
have completed, a transaction authority, in this example, the 
master transaction authority for this real estate sale, notifies each 
of the participants and each of the participating distributed 
1 0 transaction authorities, that the preconditions have all been met 
and settles the overall transaction. Optionally, the transaction 
authority may give seller and purchase a last opportunity to 
proceed to completion or to hold up the transaction. 
This one example shows that Commerce Utility Systems 90, 
1 5 including transaction authority 700, may be distributed to 

intermediate VDE protected processing environments that support 
one or more Commerce Utility Systems 90. 

Example - Digital Broadcasting Network 

20 Amortizing infrastructure and other resources across many 

users, building critical mass more rapidly than competitors, 
supporting specialization to tailor and deliver the most appealing 
products and services to customers, maximizing negotiating 
leverage power for purchasing, and building the most 

25 comprehensive infrastructure to serve as the best "one-stop" 
resource for a given business activity - these are all central 
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concepts in building successful, modern businesses. VDE and 
Distributed Commerce Utility provide a foundation for creating 
highly competitive and successful cyberspace businesses that 
demonstrate these attributes. Many of these businesses will reflect 
5 the character of the Internet and the World Wide Web. Like VDE 
and Distributed Commerce Utility, they will comprise a 
distributed community that realizes maximum advantage by 
supporting electronic commerce partnerships. They will provide 
different layers of services and complementary products and 

1 0 services, and will realize great advantage in coordinating their 
activities to their mutual benefit. 

The Digital Broadcasting Network ("DBN") will be just 
such an innovative commercial enterprise. Comprised of many 
different World Wide Web ("WEB") based sites and services, 

1 5 DBN participants will gain greater leverage and operating 

efficiency by sharing resources, experiencing maximum buying 
power, generating marketing and customer information, and 
supporting a rational administrative overlay that ties together their 
many, frequently complementary, activities. Much like the 

20 consistent rules that enable and underlie both the World Wide 
Web and the design of VDE and Distributed Commerce Utility, 
and layered upon the capabilities of both these architectures, the 
Digital Broadcasting Network employs their inventions to support 
a highly efficient, largely automated and distributed community 

25 that maximizes business efficiencies. In a similar manner, other 
examples would include other groupings of entities that function 
together as Virtual Enterprises (e.g. corporations or other 
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organizations). The distributed nature of VDE and the Commerce 
Utility Systems are particularly important in providing an effective 
infrastructure for these modern, potentially large scale, cyberspace 
business activities. 

The Digital Broadcasting Network may function as a 
cooperative of WEB sites and, for example, service providers, 
with a central and perhaps regional and logical (e.g. market based) 
headquarters groups, or it may function as a for profit, shareholder 
corporation in a business model reminiscent of television 
1 0 broadcast companies (e.g., NBC), or it may function as a 
cooperative or virtual corporation that has some mix or 
combination of mixes of the above attributes and employ 
distributed peer to peer, hierarchical, and centralized 
administrative business relationships and activities. In one 
1 5 example, a plurality of corporations may join together to provide 
the advantages of size and coordination with individual 
participants providing some degree of specialty expertise and the 
body of entities coordinating together in some fashion in a 
"higher" level cooperative or corporation. 
20 In one example, the Digital Broadcasting Network may be a 

single corporation that has many licensed franchisees. The 
licensed franchisees may comprise WEB sites that serve 
geographically and/or logically specialized market areas and/or 
serve other WEB sites in a hierarchy and/or peer-to-peer context 
25 of Distributed Commerce Utility services as described above. On 
behalf of itself and its franchisees, this corporation may, for 
example: 

319 



negotiate optimal rates for exposure time with 

advertisers and their agents, 

obtain the lowest costs for content provided by third 

parties, 

resell market analysis and user profiling information, 
share its revenue with its franchisees which themselves 
may share revenue with DBN and/or other franchisees, 
provide advertising to franchisees in response to 
franchisee and/or franchisee user base profiles, 
guarantee a certain number of "eyes" (exposures and/or 
other interactions) with respect to advertiser materials, 
provide a secure virtual network employing VDE and 
Distributed Commerce Utility capabilities so that the 
overall organization can operate in a secure and highly 
efficient manner, including using common user 
application tools, interfaces, and administration 
operations, 

do advertising for the network to the benefit of the 
network and the franchisees, 

purchase and/or otherwise supply content to franchisees 
in response to franchisee needs as demonstrated by their 
requests and/or usage profiles, 
collect and analyze content (including advertising) 
usage, cyberspace purchasing, and other data as allowed 
under its agreement with franchisees, 
allow franchisees to perform many of the network 
functions on a local basis— that is acquire and make 
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available geographically and/or logically local 
(consistent with there focus) content (and/or other 
content of particular interest to its user base), 

• negotiate agreements regarding advertising materials that 
are of commercial value given the franchisees, physical 
and/or logical market focus, 

• control at least a portion of its WEB "broadcasting" 
space— that is exercise local control over at least some 
portion of the content -with the remainder of the 
control, by agreement, and, for example, enforced by 
rules and controls, being under the control of DBN 
and/or some one or more other network participants, and 

• perform other administrative, support and/or service 
functions on behalf and/or for the network. 

In one example, DBN may employ many of the security and 
administrative capabilities of VDE and many of the service 
functions provided by the present inventions to manage and 
automate the distributed relationships and activities that are 
central to the DBN business model. For example: 

• Transaction Authority 700 can provide the overall 
administrative context for managing the network 
community. For example, the transaction authority 700 
may manage (through the use of VDE rules and controls 
in the preferred embodiment) the routing of content to 
appropriate franchisees. It may also manage the chains 
of handling and control related to reporting usage 
information. The transaction authority 700 may obtain 
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and/or derive its electronic control sets from the 
agreement relationships between DBN and its 
franchisees. Electronic negotations may be used to 
create these agreement relationships. The transaction 
authority 700 may also receive controls reflecting 
bilateral or other networked relationships directly among 
franchisees and other participants. 
Rights and Permissions Clearinghouse 400 can extend 
commercial rights related to content to network 
franchisees. It acts as a repository of rights related to 
content that is supplied by network entities to customers- 
-including content rights held by network entities 
themselves, and made available to other network entities. 
Such content rights may include, for example, 
displaying, vending, redistributing, repurposing, and for 
advertising. It can provide additional rights (e.g., 
redistribution rights or specialized repurposing rights) 
upon request and/or automated profiling based, for 
example, upon usage. 

Usage Clearinghouse 300 can collect usage data in 
support of market analysis, user profiling, and 
advertising. It may also analyze that information and 
derive reports. It may distribute those reports internally 
to the DBN as appropriate, and sell reports and/or other 
usage based information externally based upon 
commercial opportunity. 
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Financial Clearinghouse 200 can ensure proper 
compensation fulfillment throughout the network. It 
may collect payments due to DBN from franchisees for 
content. It may distribute to franchisees payments due 
them as a result of advertising and reselling of usage 
information. It can collect payments from franchisees 
for support of generaly DBN infrastructure and services 
such as, for example, network advertising. It connects to 
general purpose financial clearinghouse infrastructure to 
transmit and receive payment related information. 
The secure directory services 600 may maintain 
directory services based upon unique identity and/or 
class attributes). There may be a very large number of 
franchisees globally. Directory services 600 could also 
maintain directory information on customers, including 
unique identifier and profiling information. Secure 
directory services 600 may maintain directory 
infrastructure for content owned, managed and/or 
available to the network. 

A certifying authority 500 may certify the roles of all 
participants in the network. It would issue a certificate 
to each franchisee, for example. It may also issue 
certificates certifying commercial relationships of 
groupings of network entities to facilitate efficient, 
secure relationships with third parties. They may also 
issue certificates to customers to represent certain 
specialized customer rights regarding customer 
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commercial activities with outside parties (for example, 
discounts, or being a member of the greater "DBN" 
community). 

Portions or all of specific service functions (e.g., as 
5 . described above) may be highly distributed and may operate 
significantly, primarily or even exclusively on franchise and 
service network web servers. 

* * * * * ♦ 

1 0 While the inventions have been described in connection 

with what is presently considered to be the most practical and 
preferred embodiment, it is to be understood that the inventions 
are not to be limited to the disclosed embodiment, but on the 
contrary, are intended to cover various modifications and 

1 5 equivalent arrangements included within the spirit and scope of 
the appended claims. 
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WHAT IS CLAIMED IS: 

1 . An electronic commerce and/or rights management system for 
performing at least one clearing operation, the system comprising: 
a first electronic appliance (100), 
a second electronic appliance (1 00'), and 
an electronic communications network ( 1 50) that allows the 

first and second electronic appliances (100, 100') to exchange digital 

signals, 

characterized in that: 

the first electronic appliance (100) performs at least a first part 
of the clearing operation, and 

the second electronic appliance (100') performs at least a 
second part of the clearing operation. 

2. An electronic commerce and/or rights management system as in 
claim 1 further characterized in that the first part of the clearing operation 
includes at least one micropayment aggregation task, and the second part of 
the clearing operation includes at least one payment settlement task. 

3. An electronic commerce and/or rights management system as in 
claim 1 further characterized in that that the first electronic appliance (100) 
comprises a consumer appliance, and the second electronic appliance (100') is 
installed, at least in part, within a clearing institution. 

4. An electronic commerce and/or rights management system as in 
claim 1 further characterized in that at least the first electronic appliance (100) 
includes a protected processing environment (154). 

5. An electronic commerce and/or rights management system as in 
claim 1 further characterized in that the first part of the clearing operation 
comprises a usage metering task (116). 

6. An electronic commerce and/or rights management system as in 
claim 1 further characterized in that the first part of the clearing operation 
comprises at least one task conditioned on a digital certificate (504). 
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claim 1 further characterized in that the first part of the clearing operation 
comprises at least one rights management task. 

8. An electronic commerce and/or rights management system as in 
5 claim I further characterized in that the first part of the clearing operation 

comprises at least one electronic currency management task. 

9. An electronic commerce and/or rights management system as in 
claim 1 further characterized in that most of the clearing operation is 
performed by the first appliance (100). 

10 10. An electronic commerce and/or rights management system as in 

claim 1 further characterized in that most of the clearing operation is 
performed by the second appliance (100*). 

1 1 . An electronic commerce and/or rights management system as in 
claim 1 further characterized in that the system further includes a third 

1 5 electronic appliance (100 n ) coupled to at least one of the first and second 
electronic appliances (100, 100') through the network (150), the third 
electronic appliance performing a third part of the clearing operation. 

12. An electronic commerce and/or rights management system as in 
claim 1 further characterized in that each of the first and second appliances 

20 ( 1 00, 1 00 1 ) are capable of performing any of a financial clearing operation, a 
usage clearing operation, a rights and permissions clearing operation, a 
certifying authority operation, a transaction authority operation, and a secure 
directory services operation, and each of said operations may be distributed in 
different ways between the first and second appliances (100, 100 v ). 

25 1 3. An electronic commerce and/or rights management system as in 

claim 1 further characterized in that the electronic network (1 SO) couples the 
first and second electronic appliances (100, 1 00') to a commerce utility system 
web. 

14. An electronic commerce and/or rights management system as in 
30 claim 1 further characterized in that an electronic rights holder can 

electronically choose between the first electronic appliance (100) and the 
second electronic appliance (100 1 ). 
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claim 1 further characterized in that the first and second electronic appliances 
(1 00, 100') work together to perform overall transaction clearing. 

1 6. An electronic commerce and/or rights management system as in 
claim 1 further characterized in that each of the first and second appliances 
(100, 100') performs each of: at least one financial clearing operation, at least 
one usage clearing operation, at least one rights and permissions clearing 
operation, at least one certifying authority operation, at least one transaction 
authority operation, and at least one secure directory services operation. 

1 7. An electronic commerce and/or rights management system as in 
claim 1 further characterized in that the first electronic appliance (100) 
comprises a hierarchy of plural commerce utility systems (90(1), ... 90(n)). 

1 8. An electronic commerce and/or rights management system as in 
claim 1 further characterized in that the first electronic appliance ( 1 00) is 

15 organization-specific. 

1 9. An electronic commerce and/or rights management system as in 
claim I further characterized in that the first electronic appliance ( 1 00) is : 
vertically specialized. 

20. An electronic commerce and/or rights management system as in 
20 claim 1 further characterized in that the first electronic appliance ( 100) is 

specialized by territory and/or jurisdiction. 

2 1 . An electronic commerce and/or rights management system as in 
claim 1 further characterized in that the first and second electronic appliances 
(100, 100') communicate and coordinate as peers and in a hierarchy. 

25 22. An electronic commerce and/or rights management system as in 

claim 1 further characterized in that that clearing operation includes 
processing payment related information, and performing at least one payment 
related transaction. 

23. An electronic commerce and/or rights management system as in 

3 0 claim 1 further characterized in that that clearing operation includes 
processing usage related information and performing at least one usage 
reporting action. 
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claim 1 further characterized in that that clearing operation includes receiving 
at least one request, and performing at least one associated rights management 
transaction. 

5 25. An electronic commerce and/or rights management system as in 

claim 1 further characterized in that that clearing operation includes issuing at 
least one digital certificate. 

26. An electronic commerce and/or rights management system as in 
claim 1 further characterized in that that clearing operation includes securely 

1 0 providing directory information. 

27. An electronic commerce and/or rights management system as in 
claim I further characterized in that that clearing operation includes 
performing at least one process management transaction. 

28. An electronic commerce and/or rights management system as in 
1 5 claim 1 whether the first and second parts of the clearing operation support 

one another. 

29. An electronic commerce and/or rights management system as in 
claim 1 wherein at least one of the first and second electronic appliances (100, 
100') includes a rights operating system that supports a collection of service 

20 application components defining at least one service function. 
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AMENDED CLAIMS 

[received by the International Bureau on 5 January 1998 (05.01.98); 
original claims 1-29 replaced by new claims 1-233 (59 pages)] 

1 . A method for supporting a distributed commerce utility, wherein said 
method comprises the steps of: 

a. Establishing a central clearinghouse arrangement; 

b. Establishing plural, distributed clearinghouse nodes remote from said 
central clearinghouse arrangement, said distributed clearinghouse 
nodes securely communicating with said central clearinghouse 
arrangement; 

c. Performing digital information usage audit functions at one or more of 
said remote clearinghouse nodes; 

d. Maintaining at said one or more remote clearinghouse nodes, a 
database containing a local store of information related to multiple uses 
of digital information; 

e. Transmitting information representative of said multiple uses of digital 
information from said database(s) to said central clearinghouse 
arrangement; and 

f. Securely managing at least one aspect of said uses of said digital 
information at said one or more remote clearinghouse nodes in 
response to at least a portion of said local store of information and 
rules and controls securely and separately supplied by said 
clearinghouse arrangement and at least one third party digital 
information rightsholder 

2. A method for creating a cooperative, distributed rights management 
commercial arrangement, wherein said method comprises the steps of: 

a. Establishing plural commerce service arrangements for the 
performance of system services comprising two or more of ( 1 ) 
financial clearing, (2) usage information clearing, (3) rights and 
permissions clearing, (4) certificate authority services, (5) directory 
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17. A method for operating a rights repository system, said method 
comprising the steps of: 

a. Distributing protected commerce nodes for use by participants in 
commercial processes; 

b. Maintaining a rights repository arrangement remotely from end-user 
participants; 

c. Receiving at least in part protected digital information at an end-user 
participant commerce node; and 

d. Enabling said end-user participant node to securely, separately receive 
rights permission information from said remote rights repository to, at 
least in part, enable a desired usage of at least a portion of said digital 
information at said end-user participant commerce node. 

1 8. A method for mixed commerce infrastructure, said method comprising 
the steps of: 

a. Employing plural, distributed commerce utility systems, said 
systems operated by plural parties that provide trusted commerce services; 

b. Employing plural, distributed, trusted commerce appliances to 
support end-user electronic commerce activity; 

c. Securely conveying digital information between end-user 
commerce appliances and at least one commerce utility system; 

<L Securely conveying digital information between two or more of 
said commerce utility systems; and 

e. Securely conveying digital information between two or more of 
said end-user commerce appliances. 

19. A method for supporting a hierarchical commerce infrastructure, said 
method comprising the steps of: 

a. Establishing trusted, distributed commerce appliances; 
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services, (6) advertising management services, (7) repository, 
archiving, back-up and restore, and/or non-repudiation services, (8) 
certifying services validating that digital information and/or events 
have satisfied applicable commerce rules and controls. (9) managing 
distributed transaction processing in accordance with applicable 
commerce rules and controls, and (10) user and/or class profiling 
and/or marketing analysis including assisting in the direction of digital 
information to one or more specific parties and/or class of parties: 

b. Establishing interoperability standards enabling secure, cooperative 
use of said plural service arrangements; 

c. Providing plural system services through use of said plural service 
arrangements for use by digital information rightsholders; and 

d. Securely supporting electronic commerce at a value chain participant 
node at least in part through the use of system services provided by 
said plural commerce service arrangements. 

3. A method for supporting a distributed commerce arrangement 
comprising the steps of: 

a. Supporting multiple, separately operated service arrangements for the 
performance of electronic commerce support services; 

b. Providing digital information for use by end-users operating within 
said distributed commerce arrangements; 

c. Passing digital information reflecting end-user use of said digital 
information to plural of said separately operated service arrangements: 
and 

d. Passing digital information reflecting end-user use of said digital 
information from at least one of said separately operated service 
arrangements to at least one other of said separately operated service 
arrangements. 
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4. A method for directing the movement of digital information among 
participants in a rules and controls managed electronic commerce arrangement 
comprising the steps of: 

a. Establishing the identity of plural participants in a distributed 
electronic commerce arrangement; 

b. Acquiring user profile and/or preference information; 

c. Conveying said information to a commerce service center; 

d. Directing other digital information to an arrangement participant based 
at least in part upon said profile and/or preference information: and 

e. Ensuring satisfaction of requirements specified by at least one 
rightsholder having rights in said directed digital information, through 
use, at least in part, of rules and controls specified by said at least one 
rightsholder. 

5. A method for supporting a rules and controls based, distributed 
commerce arrangement, comprising the steps of: 

a. Establishing plural, separate commerce service providers: 

b. Establishing plural, separate value chain end-users; 

c. Supporting, at least in part securely, differing value chains made up of 
value chain participants comprising different combinations of plural, 
separate authorized commerce service providers and plural authorized 
end-users; and 

d. Transferring digital information securely between one or more end- 
user sites and plural, separate commerce service providers in response 
to commerce rules and controls established by one or more of said 
value chain participants. 
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6. A method for exchanging digital information within a distributed, 
secure, electronic commerce arrangement, comprising the steps of: 

a. Establishing unique identities for participants within an electronic 
commerce arrangement, wherein said participants comprise commerce 
utility service providers, product and/or information service providers, 
and product and/or information service users; 

b. Securely delivering a first type of digital information between an 
arrangement participant A and an arrangement participant B; 

c. Securely delivering a second type of digital information between said 
arrangement participant B and an arrangement participant C; 

d. Securely delivering a third type of digital information between 
arrangement participant C and arrangement participant D; and 

e. Protecting participant rights at least in part through programmable, 
secure, rules and controls based governance of use of said types of 
digital information delivered to, and used by, said participants B and 
C; 

wherein each of said types of digital information comprise one of: (1) 
digital content, (2) usage information related to usage of said digital content. 
(3) instructions used in fulfilling an electronic payment related to usage of said 
digital content, (4) electronic currency, (5) rules and controls, and (6) profiling 
and/or preference information of an arrangement participant 

7. A method for receiving value in response to an electronic event, said 
method comprising: 

a. Establishing a distributed computing environment supporting peer-to- 
peer, securely interoperable participant nodes; 

b. Specifying requirements that are securely associated with digital events 
for at least in part managing the processing of said events at least in 
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part within protected processing environments located at said 
participant nodes; 

c. Processing a digital event at least in part within a protected processing 
environment at a first participant's node at least in part in response to 
an event request authorized by said first participant; 

d. Requiring compensation from said first participant based, at least in 
part, on the processing of said digital event at said first participant's 
node; and 

c. Requiring compensation from a second environment participant based, 
at least in part, on providing usage information related to said digital 
event. 

8. A method for establishing identity characteristics for automating 
electronic commerce processes, wherein said method comprises the steps of: 

a. Establishing a unique identifier for a participant and/or a participant 
commerce installation; 

b. Securely issuing a first digital credential that identifies a first 
characteristic of said participant and/or participant installation: 

c. Securely issuing a second digital credential that identifies a second 
characteristic of said participant and/or participant installation; 

d. Associating plural characteristic identifying digital credentials with 
certain digital information and/or electronic events for usage 
governance; 

c Requesting at least one form of digital processing of said digital 
information; 

f. Testing for the presence of said first and second digital credentials; and 

g. Responding to said request based at least in part on said test, wherein 
said responding to said request is governed at least in part by secured 
processes operating within said participant's installation. 
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9. A method for establishing an interoperable, peer-to-peer commerce 
arrangement, wherein said method enables peers to perform certificate authority 
functions, said method comprising the steps of: 

a. Installing securely interoperable commerce nodes at end-user sites; 

b. Enabling multiple commerce node end-users to each separately issue 
certificates to other comment r*uue end-users and/or end-user 
installations; and 

c. Enabling a digital information rightsholder and/or said end-user 
certificate issuer to at least in part manage usage rights related to 
certain digital information as a result of said rightsholderand/or said 
end-user certificate issuer associating one or more said rightsholder 
and/or end-user issued certificates with certain processing of said 
digital information. 



10. A method for supporting a distributed trust platform, said method 
comprising the steps of: 

a. Securely installing, through a secure install arrangement, end-user 
electronic commerce installations of said distributed trust platform; 

b. Securely establishing a unique site identifier, 

c. Securely managing, at least in part through use of said unique site 
identifier, software installation and/or software updating; 

d Securely associating rules and controls with certain digital information: 

e. Securely distributing said digital information for use at said end-user 
electronic commerce installations; and 

f. Controlling use of at least a portion of said digital information in 
response to said associated rules and controls. 
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11. A method for reporting electronic commerce event, user profiling, and 
surveying information, said method comprising the steps of: 

a. Monitoring usage of digital information at distributed electronic 
commerce nodes; 

b. Securely communicating information related to said monitored usage 
from at least one of said commerce nodes to at least one commerce 
utility system service; 

c. In accordance with rules and controls, at least one portion of said 
reported usage related information not being provided in useable form 
to said system service: and 

d. In accordance with rules and controls related to said communicated 
usage related information, electronically communicating at least a 
portion of said not usable information to a digital information 
rightsholders. 

12. A method for distributed micro-transaction auditing and processing, 
said method comprising the steps of: 

a. Installing protected, distributed commerce nodes for auditing usage of 
digital information; 

b. Managing micro-payment related activity related to said usage of 
digital information at a commerce node based, at least in pan. on 
control information provided by a first party; and 

c Securely reporting information reflecting said commerce node auditing 
of usage information from said commerce node to a commerce utility 
system based, at least in part, on control information provided by a 
second party different from said first party. 
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13. A method for transaction authority management of distributed 
commercial activities, said method comprising the steps of; 

a. Employing a transaction authority to assist in the governance of a 
distributed commercial process; 

b. Participating by plural parties in a distributed commercial process via 
electronic instructions; and 

c. Governing, at least in part, said distributed commercial process 
through the use of secure control information contributed by said 
transaction authority and, at least in part, through the use of peer-to- 
peer commercial participant secure commerce nodes. 

14. A method for operating a distributed electronic security checkpoint 
system, said method comprising the steps of: 

a. Employing distributed checkpoint electronic switches in a 
communications network; 

b. Communicating through said network, at least in part secured digital 
information provided by a first commercial party, said secured digital 
information to be at least in part received by at least one of said 
checkpoint electronic switches; 

c. Interacting with at least a portion of said received secured information 
through operation of at least one of said checkpoint electronic switches 
to: (1) acquire information related to said secured information, and/or 
(2) certify, authenticate, validate, and/or otherwise assert and/or test 
said information so as to provide a trusted commerce service; and 

d. Further communicating at least a portion of said secured digital 
information from said distributed checkpoint electronic switch to a 
second, remotely located commercial party different from said first 
commercial party. 
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15. A method for operating a digital broadcasting network, said method 
comprising the steps of: 

a) Securely providing digital information to plural participants in a 
cooperative arrangement of network information hosting and/or other 
service parties; 

b) Basing variables related to said digital information provided by step (a), at 
least in part upon specific attributes of each said party and/or classes of 
said parties; 

c) Commercially redistributing at least a portion of said digital information 
from at least certain of said parties to further parties: and 

d) Representing said cooperative arrangement to directly and/or electronically 
negotiate compensation arrangements related to said provision of digital 
information. 

16. A method for supporting a secure messaging system, said method 
comprising the steps of: 

a. Packaging digital information at least in pan securely in an electronic 
container for transmission by a first party to at least one additional 
party; 

b. Employing a directory service to provide electronic address 
information to direct said container to said at least one additional party; 

c. Transmitting said container to said at least one additional party; 

d. Providing authentication for at least a part of said digital information 
and/or for said secure container; and 

e. Preventing said first party from effectively denying that said first party 
sent at least a portion of said digital information and/or said container 
to said at least one additional party. 
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b. Establishing a programmed hierarchical rights management 
relationship between plural of said distributed commerce appliances and/or 
users of said distributed commerce appliances; and 

c. Separately producing, at least in part in combination with at least a 
portion of said programmed hierarchical rights relationship and at least in part 
by the action of a hierarchically more senior: (1) distributed commerce 
appliance, (2) user using a distributed commerce appliance, (3) distributed 
commerce appliance and user, or (4) plurality of any one or more of (1), (2), 
and (3) in combination, control information for specifically managing specific 
activities performed by hierarchically less senior said distributed commerce 
appliances and/or users of said distributed commerce appliances. 

20. A method for supporting a hierarchical commerce utility system 
infrastructure, said method comprising the steps of: 

a. Establishing a first trusted commerce utility system; 

b. Establishing a second trusted commerce utility system 
hierarchically less senior than said first trusted commerce utility system; 

c. Securely communicating control information between said first and 
second commerce utility systems; 

d. Establishing trusted end-user commerce nodes; and 

e. Performing by said second commerce utility system a commerce 
utility service function servicing at least one of said end-user commerce nodes, 
wherein Said service operates at least in part in accordance with said securely 
communicated control information, 

21. A method for supporting a virtual computer, said method 
comprising the steps of: 

a. Establishing distributed commerce nodes; 
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b. Establishing a trusted commerce utility system to at least in pan 
manage use rights related to resources available at one or more of said 
distributed commerce nodes; 

c. Establishing use rights information to at least in part govern use of 
physical and/or logical resources available for use at, at least one of. said one 
or more distributed commerce nodes; 

d. Securely communicating at least a portion of said use rights 
information to said at least one of said distributed commerce nodes; ande. 
Employing resources at said at least one of said distributed commerce nodes 
for use in a virtual computing arrangement based, at least in part, on said use 
rights information. 

22. A method for supporting virtual, networked banking activities, said 
method comprising the steps of: 

a. Enabling plural banking arrangements that comprise a web of 
separately managed protected processing environments; 

b. Communicating control information securely between plural of said 
separately managed protected processing environments; 

c. Governing one or more banking activities, by at least in part managing 
interacting electronic processes, at least in part operating under the control of 
plural said banking arrangements' protected processing environments, where said 
processes are managed by rules and controls and are related to one or more of: (1 ) 
the electronic storage of currency, (2) the right to lend money to at least one 
participant, (3) the fulfillment of payment obligations, (4) the management of 
electronic bills and/or other obligations, and (5) the ability to deliver or otherwise 
communicate one or more currency objects. 
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23. A method for supporting payment settlement related, at least in part, t< 
electronically rights managed electronic commerce, said method comprising the 
steps of: 

a. Enabling a financial clearinghouse employing at least one protected 
processing environment to securely receive payment related information from 
distributed electronic commerce nodes located at remote end-user sites; 

b. Securely receiving at said clearinghouse payment related information 
from at least one of said distributed electronic commerce nodes; 

c. Processing, within at least one protected processing environment at said 
clearinghouse, at least a portion of said payment related information including 
governing payment fulfillment at least in part based upon electronic rights 
management control information processed ; and 

d. Securely communicating payment fulfillment information to at least 
one of (1) a payment fulfillment organization, and (2) an intended recipient of 
payment, wherein said payment fulfillment organization and/or intended recipient 
of payment at least in part employ a protected processing environment to access 
said payment fulfillment information. 

24. A method for supporting a fulfillment server, said method comprising 
the steps of: 

a. Establishing a fulfillment server for efficiendy managing, at least in 
part, electronic requests; 

b. Securely receiving electronic request information from a distributed, 
secure electronic commerce node; 

c. Securely receiving from a remote location rule based control 
information securely associated with said electronic request information, said 
control information operating with fulfillment server control information to form 
at least one control set; 
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d. Testing to determine what action should be taken with respect to said 
request information, through the use of at least a portion of said control set; 

e. Securely responding to said distributed electronic commerce node to 
provide feedback regarding said request information; and 

f. Processing, in accordance with at least a portion of said at least one 
control set a request described by said request information, by one or more of: (a) 
fulfilling said request (b) partially fulfilling said request, (c) not fulfilling said 
request and (d) seeking further information related to said request. 

25. A method for supporting delegated electronic rights, said method 
comprising the steps of: 

a. Establishing distributed trusted electronic commerce nodes for use by 
plural separate parties; 

b. Associating a digital credential with one or more parties and/or nodes, 
where said credential, in combination with protected control information, provides 
the right to said one or more parties and/or nodes to electronically represent and/or 
exercise rights possessed by one or more other parties and/or nodes; and 

c. Enabling said provision of at least one right to represent and/or 
exercise, at least in part, through the use of electronic control information 
including governing said right to represent and/or exercise by processing at least a 
portion of said control information in at least one trusted electronic commerce 
node, 

26. A method for supporting a virtual entity, said method comprising the 
steps of: 

a. Installing distributed, trusted electronic commerce nodes for use by 
plural parties; 

b. Issuing digital credentials to plural parties and/or nodes to. at least in 
part, represent the identity of said parties and/or nodes; 
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c. Securely communicating, among said plural parties and/or nodes, 
digital information related to at least in part the identity of said panics and/or 
nodes; 

d. Securely creating, within one or more said trusted electronic commerce 
nodes, one or more digital credentials that represents a virtual entity that 
comprises a cooperative participation among said plural parties and/or nodes for 
one or more commercial purposes; and 

e. Employing at least one of said one or more credentials representing said 
virtual entity to, at least in part, enable said virtual entity to at least in part 
participate in at least one commercial process 

27. A method for securely electronically delivering digital information, 
said method comprising the steps of: 

a. Securely communicating selected digital information between two or 
more participant parties supported by at least one trusted service provider 
participants, all said participants employing protected electronic environments, 
wherein said trusted provider supports archiving and/or authenticating of 
transaction related information; 

b. Securely generating secure control information at two or more of said 
trusted lectronic environments; 

c. Securely governing at least a portion of said communicating and use of 
said selected, communicated digital information through use of said generated 
control information; 

d. Storing information related to communication and/or usage of said 
communicated digital information at each participant site; and 

e. Performing by said service provider participant trusted archival and/or 
authentication services related to said selected digital information 
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28. A method for reporting clertronic commerce event, user profiling, and 
surveying information, said method comprising the steps of: 

a. Monitoring usage of digital information at one or more distributed 
electronic commerce nodes; 

b. Collecting user profiling and/or survey information; 

c. Securely reporting information related to said user profiling and/or 
surveying from at least one said commerce nodes to at least one 
commerce utility system services; and 

d. In accordance with rules and controls associated with said 
communicated profile and/or survey related information, electronically 
instructing said system service to electronically communicate to at 
least one digital information rightsholder, certain of said user profiling . 
and surveying information related to usage. 

29. A method for supporting a third party certification authority, said 
method comprising the steps of: 

a. Operating a trusted third party certification authority arrangement: 

b. Operating three or more electronic commerce participant sites: 

c. Certifying by said trusted certification authority arrangement at 
least one commercial capability, commitment, and/or other attribute possessed 
by and/or involving at least two of said three or more electronic commerce 
participant sites and/or users of said sites; 

d. Securely providing a digital credential resulting from step c. to at 
least one electronic commerce participant site different from said electronic 
commerce participant sites involved in step c; and 

c. Employing said digital credential at said at least one different 
electronic commerce participant site in the performance of a commercial 
activity. 
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30. A method for coupling trusted and untrusted activities at a trusted 
service provider, said method comprising the steps of: 

a. Operating plural end user commerce nodes; 

b. Operating plural trusted service provider arrangements for at least 
in part supporting commercial activities related to said commerce nodes; 

c. Employing a computer operating environment for each of such 
trusted service provider arrangements; 

d. Employing at least one trusted system component within such 
operating environments, wherein at least certain internal operations of said 
components are concealed from such service providers; and 

e. Performing at least one concealed process within such internal 
trusted component, wherein such concealed process is operatively coupled to 
at least one process at such trusted service provider arrangement that occurs 
external to said trusted component and is not concealed 

3 1 . A method as in claim 1 further including allowing an end user to 
choose between different central clearinghouse arrangements. 

32. A method as in claim 1 further including the step of implementing 
said plural, distributed clearinghouse nodes using protected processing 
environments that employ a secure processing unit and/or a tamper-resistant 
software environment 

33. A method as in claim 1 further including the step of implementing 
said plural, distributed clearinghouse nodes using secure databases. 

34. A method as in claim 1 further including the step of implementing 
said central clearinghouse arrangement using a protected processing environment 
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that employs a secure processing unit and/or a tamper-resistant software 
environment 

35. A method as in claim 1 further including the step of implementing 
said central clearinghouse arrangement using a secure database. 

36. A method as in claim 2 further including allowing an end user to 
choose among said plural service arrangements. 

37. A method as in claim 2 further including the step of implementing 
said value chain participant node using a protected processing environment that 
employs a secure processing unit and/or a tamper-resistant software environment. 

38. A method as in claim 2 further including the step of implementing 
said value chain participant node using a secure database. 

39. A method as in claim 2 further including the step of implementing 
said plural commerce service arrangements using protected processing 
environments that employ secure processing units and/or a tamper-resistant 
software environments. 

40. A method as in claim 2 further including the step of implementing 
said plural commerce service arrangements using secure databases. 

41. A method as in claim 3 further including allowing at least one of said 
end-users to choose among said separately operated service arrangements. 
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42. A method as in claim 3 further including the step of implementing end 
user electronic nodes using protected processing environments that employ secure 
processing units and/or a tamper-resistant software environments. 



43. A method as in claim 3 further including the step of implementing end 
user electronic nodes using secure databases. 

44. A method as in claim 3 further including the step of implementing 
said separately operated service arrangements using at least one protected 
processing environment that employs a secure processing unit and/or a tamper- 
resistant software environment, 

45. A method as in claim 3 further including the step of implementing 
said separately operated service arrangements using secure databases. 

46. A method as in claim 4 further including allowing at least one of said 
plural participants to choose among different commerce service centers. 

47. A method as in claim 4 further including the step of implementing end 
user electronic nodes using a protected processing environments that employ 
secure processing units and/or a tamper-resistant software environments. 

48. A method as in claim 4 further including the step of implementing end 
user electronic nodes using secure databases. 

49. A method as in claim 4 further including the step of implementing 
said commerce service center using at least one protected processing environment 
that employs a secure processing unit and/or a tamper-resistant software 
environment 
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50. A method as in claim 4 further including the step of implementing 
said commerce service center using at least one secure database. 

51. A method as in claim 5 further including allowing at least one end 
user to choose among said plural, separate commerce service providers. 

52. A method as in claim 5 further including the step of implementing 
said one or more end user sites using protected processing environments that 
employ secure processing units and/or tamper-resistant software environments. 

53. A method as in claim 5 further including the step of implementing 
said one or more end user sites using secure databases. 

54. A method as in claim 5 further including the step of implementing 
said plural, separate commerce service providers using protected processing 
environments that employ secure processing units and/or tamper-resistant 
software environments. 

55. A method as in claim 5 further including the step of implementing 
said plural, separate commerce service providers using secure databases. 

56. A method as in claim 6 further including allowing at least one of said 
product and/or information service users to choose among different ones of said 
commerce utility service providers, and/or product and/or information service 
providers. 

57. A method as in claim 6 further including the step of providing to each 
of said product and/or information service users, protected processing 
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environments that employ secure processing units and/or tamper-resistant 
software environments. 

58. A method as in claim 6 further including the step of maintaining a 
secure database for each of said product and/or information service users. 

59. A method as in claim 6 further including the step of providing to said 
commerce utility service providers, and/or product and/or information service 
providers, protected processing environments that employ secure processing units 
and/or tamper-resistant software environments. 

60. A method as in claim 6 further including the step of providing to said 
commerce utility service providers, and/or product and/or information service 
providers, secure databases. 

61. A method as in claim 7 further including the step of implementing 
said peer-to-peer, securely interoperable participant nodes with protected 
processing environments that employ secure processing units and/or tamper- 
resistant software environments. 

62. A method as in claim 7 further including the step of implementing 
said peer-to-peer, securely interoperable participant nodes using secure databases. 

63. A method as in claim 8 further including the step of implementing 
said participant installation with a protected processing environment that employs 
a secure processing unit and/or a tamper-resistant software environment. 

64. A method as in claim 8 further including the step of implementing 
said participant installation using a secure database. 
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65. A method as in claim 8 wherein at least one of said first and second 
digital credentials comprises a digital certificate. 

66. A method as in claim 9 further including the step.of implementing 
said securely interoperable commerce nodes with protected processing 
environments that employ secure processing units and/or tamper-resistant 
software environments. 

67. A method as in claim 9 further including the step of implementing 
said securely interoperable commerce nodes using secure databases. 

68. A method as in claim 10 further including the step of implementing *:r 
said end-user electronic commerce installations with protected processing 
environments that employ secure processing units and/or tamper-resistant 
software environments. 

69. A method as in claim 10 further including the step of implementing 
said end-user electronic commerce installations using secure databases. 

70. A method as in claim 1 1 further including allowing an end user of at 
least one of said distributed electronic commerce nodes to choose among plural 
said commerce utility systems. 

71. A method as in claim 1 1 further including the step of implementing 
said distributed electronic commerce nodes with protected processing 
environments that employ secure processing units and/or tamper-resistant 
software environments. 
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72. A method as in claim 1 1 further including the step of implementing 
said distributed electronic commerce nodes using secure databases. 

73. A method as in claim 1 1 further including the step of implementing 
said commerce utility systems with protected processing environments that 
employ secure processing units and/or tamper-resistant software environments. 

74. A method as in claim 1 1 further including the step of implementing 
said commerce utility systems using secure databases. 

75. A method as in claim 12 further including allowing an end user of at 
least one of said protected, distributed commerce nodes, to choose among plural 
said commerce utility systems. 

76. A method as in claim 12 further including the step of implementing 
said protected, distributed commerce nodes with protected processing 
environments that employ secure processing units and/or tamper-resistant 
software environments. 

77. A method as in claim 12 further including the step of implementing 
said protected, distributed commerce nodes using secure databases. 

78. A method as in claim 12 further including the step of implementing 
said commerce utility system with a protected processing environment that 
employs a secure processing unit and/or a tamper-resistant software environment. 

79. A method as in claim 12 further including the step of implementing 
commerce utility systems using secure databases. 
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80. A method as in claim 13 further including allowing an end user of said 
commercial participant secure commerce nodes, to choose among plural said 
transaction authorities. 

8 1 . A method as in claim 1 3 further including the step of implementing 
said commercial participant secure commerce nodes with protected processing 
environments that employ secure processing units and/or tamper-resistant 
software environments. 

82. A method as in claim 1 3 further including the step of implementing 
said commercial participant secure commerce nodes using secure databases. 

83. A method as in claim 1 3 further including the step of implementing 
transaction authorities with protected processing environments that employ secure 
processing units and/or tamper-resistant software environments. 

84. A method as in claim 13 further including the step of implementing 
transaction authorities using secure databases. 

85. A method as in claim 14 further including allowing at least one of said 
commercial parties to choose among plural distributed checkpoint electronic 
switch services. 

86. A method as in claim 14 further including the step of implementing 
said distributed checkpoint electronic switches with protected processing 
environments that employ secure processing units and/or tamper-resistant 
software environments. 
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87. A method as in claim 14 farther including the step of implementing 
said distributed checkpoint electronic switches using secure databases. 

88. A method as in claim 15 further including allowing at least one of said 
parties to choose among plural of cooperative arrangements. 

89. A method as in claim 1 5 further including the step of implementing 
said cooperative arrangement with a protected processing environment that 
employs a secure processing unit and/or a tamper-resistant software environment 

90. A method as in claim 1 5 farther including the step of implementing 
said cooperative arrangement using a secure database. 

91 . A method as in claim 16 farther including allowing said additional 
party to choose among plural secure messaging systems. 

92. A method as in claim 16 farther including the step of implementing 
said secure messaging system with a protected processing environment that 
employs a secure processing unit and/or a tamper-resistant software environment. 

93. A method as in claim 16 further including the step of implementing 
said secure messaging system using a secure database. 

94. A method as in claim 1 7 further including allowing an end user 
participants to choose among plural said rights repository arrangements. 

95. A method as in claim 1 7 further including the step of providing said 
end user participants with protected processing environments that employ secure 
processing units and/or tamper-resistant software environments. 
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96. A method as in claim 17 further including the step of providing said 
end user participants with secure databases. 

97. A method as in claim 17 further including the step of implementing 
said rights repository arrangements with protected processing environments that 
employ secure processing units and/or tamper-resistant software environments. 

98. A method as in claim 1 7 further including the step of implementing 
said rights repository arrangements using secure databases. 

99. A method as in claim 1 8 further including allowing an end-user to 
choose among plural said commerce utility systems. 

1 00. A method as in claim 1 8 further including the step of implementing 
said commerce utility systems with protected processing environments that 
employ secure processing units and/or tamper-resistant software environments. 

1 0 1 . A method as in claim 1 8 further including the step of implementing 
said commerce utility systems using secure databases. 

1 02. A method as in claim 1 9 further including the step of implementing 
said distributed commerce appliances with protected processing environments that 
employ secure processing units and/or tamper-resistant software environments. 

103. A method as in claim 1 9 further including the step of implementing 
said distributed commerce appliances using secure databases. 
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104. A method as in claim 19 wherein said trusted, distributed commerce 
appliances employ protected processing units. 

105. A method as in claim 20 further including allowing an end-user to 
choose among plural said commerce utility systems. 

106. A method as in claim 20 further including the step of implementing 
said commerce utility systems with protected processing environments that 
employ secure processing units and/or tamper-resistant software environments. 

107. A method as in claim 20 further including the step of implementing 
said commerce utility systems using secure databases. 

108. A method as in claim 21 further including the step of implementing 
said distributed commerce nodes with protected processing environments that 
employ secure processing units and/or tamper-resistant software environments. 

109. A method as in claim 21 further including the step of implementing 
said distributed commerce nodes using secure databases. 

1 10. A method as in claim 22 further including allowing an end user of a 
protected processing environment to choose amongst commerce utility service 
providers. 

1 1 1 . A method as in claim 22 further including implementing said 
protected processing environments with secure processing units and/or a tamper- 
resistant software environments. 
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1 12. A method as in claim 22 further including providing a secure 
database at each of said protected processing environments. 

1 13. A method as in claim 23 further including allowing an end user to 
choose among plural financial clearinghouses. 

1 14. A method as in claim 23 further including implementing said 
protected processing environments with secure processing units and/or tamper- 
resistant software environments. 

1 15. A method as in claim 23 further including providing secure databases 
at each of said protected processing environments. 

1 16. A method as in claim 23 further including the step of implementing * 
financial clearinghouses with protected processing environments that employ 
secure processing units and/or tamper-resistant software environments. 

1 17. A method as in claim 23 further including the step of implementing 
financial clearinghouses using secure databases. 

1 18. A method as in claim 24 further including allowing an end user of 
said distributed electronic commerce node to choose between plural fulfillment 
servers. 

119. a method as in claim 24 further including the step of implementing 
said distributed electronic commerce node with a protected processing 
environment that employs a secure processing unit and/or a tamper-resistant 
software environment 
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120. A method as in claim 24 further including the step of implementing 
said distributed electronic commerce node using a secure database. 

121 . A method as in claim 24 further including the step of implementing 
said fulfillment server with a protected processing environment that employs a 
secure processing unit and/or a tamper-resistant software environment. 

122. A method as in claim 24 further including the step of implementing 
said fulfillment server using a secure database. 

123. A method as in claim 25 further including the step of implementing 
said distributed trusted electronic commerce nodes with protected processing 
environments that employ secure processing units and/or tamper-resistant 
software environments. 

124. A method as in claim 25 further including the step of implementing 
said distributed trusted electronic commerce nodes using secure databases. 

125. A method as in claim 26 further including the step of implementing 
said distributed trusted electronic commerce nodes with protected processing 
environments that employ secure processing units and/or tamper-resistant 
software environments. 

126/ A method as in claim 26 further including the step of implementing 
said distributed trusted electronic commerce nodes using secure databases. 

127. A method as in claim 27 further including allowing at least one of 
said participant parties to choose among plural ones of said at least one trusted 
service provider participants. 
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128. A method as in claim 27 further including the step of providing to 
said participant parties, protected processing environments that employ secure 
processing units and/or tamper-resistant software environments. 

129. A method as in claim 27 further including the step of providing 
secure databases in protected electronic environments to participant parties. 

1 30. A method as in claim 27 further including the step of providing to 
said trusted service provider participants, protected electronic environments that 
employ secure processing units and/or tamper-resistant software environments. 

13 1 . A method as in claim 27 further including the step of providing 
secure databases to said at least one trusted service provider participant 

132. A method as in claim 28 further including allowing end users of said 
distributed electronic commerce nodes to choose among said at least one 
commerce utility system services. 

133. A method as in claim 28 further including the step of implementing 
said distributed electronic commerce nodes with protected processing 
environments that employ a secure processing units and/or tamper-resistant 
software environments. 

134. A method as in claim 28 further including the step of implementing 
said distributed electronic commerce nodes using secure databases. 

135. A method as in claim 28 further including the step of implementing 
said at least one commerce utility system services with protected processing 
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environments that employ secure processing units and/or tamper-resistant 
software environments. 

136. A method as in claim 28 further including the step of implementing 
said at least one commerce utility system services using secure databases. 

137. A method as in claim 29 further including allowing participants to 
choose among plural trusted certification authority arrangements. 

138. A method as in claim 29 further including the step of implementing 
said electronic commerce participant sites with protected processing environments 
that employ secure processing units and/or tamper-resistant software 
environments. 

139. A method as in claim 29 further including the step of implementing 
said electronic commerce participant sites using secure databases. 

140. A method as in claim 29 further including the step of implementing 
said trusted certification authority arrangement with a protected processing 
environment that employs a secure processing unit and/or a tamper-resistant 
software environment 

141. A method as in claim 29 further including the step of implementing 
said trusted certification authority arrangement using a secure database. 

142. A method as in claim 30 further including allowing an end user of at 
least one of said plural end user commerce nodes to choose among plural trusted 
service provider arrangements. 
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143. A method as in claim 30 further including the step of implementing 
said plural end user commerce nodes with protected processing environments that 
employ secure processing units and/or tamper-resistant software environments. 

144. A method as in claim 30 further including the step of implementing 
said plural end user commerce nodes using secure databases. 

145. A method as in claim 30 further including the step of implementing 
said computer operating environments with protected processing environments 
that employ secure processing units and/or tamper-resistant software 
environments. 

146. A method as in claim 30 further including the step of providing said 
computer operating environments with secure databases. 

147; A method as in any one of the preceding claims further including 
performing a negotiation process that supports bidding, auctions or electronic 
contracts. 

148. A method as in any one of the preceding claims further including the 
step of supporting a secure multiparty negotiation process. 

149. A method as in any one of the preceding claims further including the 
step of supporting the independent delivery of rules and control information. 

150. A method as in any one of the preceding claims further including the 
step of delivering control information independently of content information that is 
to be controlled by said control information. 
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1 5 1 . A method as in any one of the preceding claims further including the 
step of allowing a value chain participant to stipulate at least one aspect of 
information privacy control. 

152. A method as in claim 6 wherein arrangement participant A or 
arrangement participant B is the same as arrangement participant D. 

153. A method as in claim 8 wherein at least one of said first and second 
digital credentials comprises a digital certificate. 

154. A method as in claim 19 wherein said trusted, distributed commerce 
appliances comprise a distributed commerce utility system. 

155. A method as in claim 1 1 wherein differing said usage information is 
reported to different rightsholders as specified by rules and controls, and said 
usage information includes at least a portion of said information not provided in 
useable form to said system service is provided to at least one of said rightsholders 
in usable form. 

1 56. An electronic clearing arrangement including a central clearinghouse 
arrangement coupled to plural, distributed clearinghouse nodes remote from said 
central clearinghouse arrangement, said distributed clearinghouse nodes securely 
communicating with said central clearinghouse arrangement, one or more of said 
remote clearinghouse nodes performing digital information usage audit functions 
and maintaining a database containing a local store of information related to 
multiple uses of digital information, said electronic clearing arrangement 
characterized by: 
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an electronic arrangement at said central clearinghouse arrangement that 
receives secure information representative of said multiple uses of digital 
information from said database(s); and 

an electronic arrangement that securely supplies rules and controls to said 
remote clearinghouse nodes, whereby at least one aspect of said uses of said 
digital information is securely managed in response to at least a portion of said 
rules and controls, rules and controls securely and separately supplied by at least 
one third party digital information rightsholder, and said local store of 
information. 

157. A cooperative, distributed rights management commercial system for 
providing plural system services for use by digital information rights holders, said 
system comprising: 

plural commerce service arrangements for the performance of system 
services comprising two or more of (1) financial clearing, (2) usage information* 
clearing, (3) rights and permissions clearing, (4) certificate authority services, (5) 
directory services, (6) advertising management services. (7) repository, archiving, 
back up and restore, and/or non-repudiation services. (8) certifying services 
validating that digital information and/or events have satisfied applicable 
commerce rules and controls, (9) managing distributed transaction processing in 
accordance with applicable commerce rules and controls, and (10) user and/or 
class profiling and/or marketing analysis including assisting in the direction of 
digital information to one or more specific parties and/or class of parties, said 
plural commerce service arrangements being interoperable with one another to 
enable secure, cooperative use of said plural service arrangements: and 

an electronic arrangement wherein said plural commerce service 
arrangements are capable of securely communicating with value chain participant 
nodes, said value chain participant nodes securely supporting electronic commerce 
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at least in part through the use of system services provided by plural said 
commerce service arrangements. 

158. A distributed commerce system supporting end-users operating 
within said system, said end-users using digital information, said system 
comprising: 

plural, separately operated service arrangements for the performance of 
electronic commerce support services, said plural, separately operated service 
arrangements receiving digital information reflecting at least a portion of said end- 
user use of said digital information, said plural, separately operated service 
arrangements each including a secure communications arrangement for passing 
digital information reflecting end-user use of said digital information to at least 
one other of said plural separately operated service arrangements. 

1 59. A rules and controls managed electronic commerce system apparatus 
for directing the movement of digital information among participants comprising: 

at least one identity establishing element that establishes the identity of 
plural participants in said distributed electronic commerce system: 

at least one information acquiring element that acquires user profile and/or 
preference information associated with said participants and conveys said 
information to at least one commerce service arrangement: 

said commerce service arrangements directing other digital information to 
at least one of said participants based at least in part upon said conveyed profile 
and/or preference information; and 

at least one secure element that ensures satisfaction of requirements 
specified by at least one rightsholder having rights in said directed digital 
information, through use, at least in part, of control information specified by at 
least one rightsholder. 
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160. A rules and controls based, distributed commerce apparatus 
comprising: 

plural, separate commerce service provider sites; 
plural, separate value chain end-user sites; 

at least one value chain defining element that supports, at least in part 
securely, differing value chains made up of value chain participants comprising 
different combinations of plural, separate authorized ones of said commerce 
service providers and plural authorized ones of said end-users: and 

a communications arrangement that transfers digital information securely " . 
between one or more end-user sites and plural, separate commerce service 
provider sites in response to commerce rules and controls established by one or 
more of said value chain participants. 

161. A distributed, secure, electronic commerce system having 
participants comprising commerce utility service providers, product providers', and 
product users, said system comprising: 

means for establishing unique identities for participants within said 
electronic commerce system; 

means for securely delivering a first type of digital information between a 
system participant A and a system participant B; 

means for securely delivering a second type of digital information between 
said system participant B and a system participant C; 

means for securely delivering a third type of digital information between 
said system participant C and a system participant D; and 

means for protecting participant rights at least in part through 
programmable, secure, rules and controls based governance of use of said types of 
digital information delivered to, and used by, said participants B and C. 

wherein each of said types of digital information comprise one of: ( 1 ) 
digital content (2) usage information related to usage of said digital content. (3) 
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instructions used in fulfilling an electronic payment related to usage of said digital 
content, (4) electronic currency, (5) rules and controls, and (6) profiling and/or 
preference information of a participant. 

162. A distributed computing system supporting peer-to-peer, securely 
interoperable participant nodes including protected processing environments 
located at said participant nodes, said system ensuring that value is received in 
response to an electronic event, said system comprising: 

means for enabling the specification of requirements that may be securely 
associated with discrete digital events for at least in part managing the processing 
of said events at least in part within said protected processing environments 
located at said participant nodes; 

means for processing a digital event at least in part within a protected 
processing environment at a first participant's node at least in pan in response to 
an event request authorized by said first participant; 

means for requiring compensation from said first participant based, at least 
in part, on the processing of said digital event at said first participant's node: and 
means for requiring compensation from a second system participant based, 
at least in part, on providing usage information related to said digital event. 

163. Apparatus for establishing identity characteristics for automating 
electronic commerce processes, wherein said apparatus comprises: 

means for establishing a unique identifier for a participant and/or a 
participant commerce installation; 

means for securely issuing a first digital credential that identifies a first 
characteristic of said participant and/or participant installation: 

means for securely issuing a second digital credential that identifies a 
second characteristic of said participant and/or participant installation: 
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means for associating plural digital credentials corresponding to said 
characteristics with certain digital information and/or electronic events for usage 
governance; 

means for requesting at least one form of digital processing of said digital 
information; 

means for testing for the presence of said first and second digital 
credential; and 

means for responding to said request based at least in part on said test, 
wherein said responding to said request is governed at least in part by secured 
processes operating within said participant's installation. 

164. An interoperable, peer-to-peer commerce system for enabling peers 
to perform certificate authority functions, said system including plural commerce 
node end-users having associated end-user installations, and at least one digital 
information rightsholder, said system comprising: 

at least one securely interoperable commerce node at a site of a first 
commerce node end user; 

means for enabling said first end user to issue certificates to others of said 
commerce node end-users and/or end-user installations; and 

means for enabling said digital information rightsholder and/or said first 
end user to at least in part manage usage rights related to certain digital 
information as a result of said rightsholder and/or said first end-user associating 
one or more said end-user issued certificates with certain processing of said digital 
information. 

165. A distributed trust platform comprising: 

means for securely establishing a unique site identifier. 



366 

AMENDED SHEET (ARTICLE 19) 



WO 98/10381 



PCT/US96/14262 



a secure installation arrangement for securely installing end-user electronic 
commerce installations and for securely managing software installation and/or 
software updating; 

means for securely associating rules and controls with certain digital 
information; 

means for securely distributing said digital information for use at said end- 
user electronic commerce installations; and 

means for controlling use of at least a portion of said digital information in 
response to said associated rules and controls. 

1 66. An arrangement for reporting electronic commerce event, user 
profiling, and surveying information in the context of a system including 
distributed electronic commerce nodes including means for monitoring usage of 
digital information and means for securely reporting at least a pan of information 
related to said monitored usage from said commerce nodes to at least one 
commerce utility system service, at least one portion of said reported usage related 
information not, in accordance with rules and controls, being provided in useable 
form to said system service, further characterized by: 

an arrangement that electronically instructs said system service, in 
accordance with rules and controls associated with said reported usage related 
information, to electronically report to digital information rightsholders. 

167. Distributed electronic system apparatus for supporting distributed 
micro-transaction auditing and processing, said apparatus comprising: 

protected, distributed commerce nodes for auditing usage of digital 
information, plural of said commerce nodes including means for managing micro- 
payment related activity related to said usage of digital information based, at least 
in part, on control information provided by a first party; and 



367 

AMENDED SHEET (ARTICLE 19) 



WO 98/10381 



PCT/US96/14262 



at least one commerce utility system that securely receives information 
reflecting said commerce node auditing of usage information reported by plural of 
said protected, distributed commerce nodes based, at least in part, on control 
information provided by a second party different from said first party. 

168- In a system including peer-to-peer commercial participant secure 
commerce nodes for permitting plural parties to participate in a distributed 
commercial process via electronic instructions, apparatus for transaction authority 
management of distributed commercial activities, said apparatus comprising: 

a transaction authority for assisting in the governance of a distributed 
commercial process, said transaction authority contributing secure control 
information for use in governing, at least in part, said distributed commercial 
process; and 

means at said peer-to-peer commercial participant secure commerce nodes 
for at least in pan enforcing said governance. 

1 69. In a communications network for communicating at least in part 
secured digital information provided by a first commercial party to a second 
commercial party different from said first commercial party, a distributed 
electronic security checkpoint system comprising: 

at least one checkpoint electronic switch for at least in part receiving said 
secured digital information, and for interacting with at least a portion of said 
received secured information, including means for acquiring information related 
to said secured information, and/or means for at least one of certifying, 
authenticating, validating, and/or otherwise asserting and/or testing said 
information so as to provide a trusted commerce service, said checkpoint 
electronic switch including a communications arrangement for further 
communicating at least a portion of said secured digital information to said second 
commercial party different from said first commercial party. 
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170. A digital broadcasting network, said apparatus comprising: 
means for securely providing digital information to plural participants ir 

cooperative arrangement of network information hosting and/or other service 

parties; 

means for basing variables related to said provision of said digital 
information at least in part upon the specific attributes of each said party and/or 
classes to which said parties belong; 

means for commercially redistributing at least a portion of said digital 
information from at least certain of said parties to further parties: and 

means for representing said cooperative arrangement to directly and/or 
electronically negotiate compensation arrangements related to said provision of 
digital information. 



1 71 . A secure messaging system comprising: 

means for packaging digital information, at least in part securely, in an 
electronic container for transmission by a first party; 

means for employing a directory service to provide electronic address 
information to direct said container to at least one additional party: 

means for transmitting said container to said at least one additional party; 

means for providing authentication for at least a pan of said digital 
information and/or for said container; and 

means for preventing said first party from effectively denying that said 
first party sent at least a portion of said digital information and/or said container to 
said at least one additional party. 

172, In a distributed electronic commerce system including plural 
protected end-user participant commerce nodes distributed for use by end-user 
participants in commercial processes, said end-user participant commerce nodes 
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receiving at least in part protected digital information, a rights repository 
arrangement disposed remotely from said end-user participants, said rights 
repository enabling said end-user participant node to securely, separately receive 
rights permission information from said remote rights repository to. at least in 
part, enable a desired usage of at least a portion of said digital information at said 
end-user participant commerce node. 

173. A mixed commerce infrastructure comprising: 

plural, distributed commerce utility systems providing trusted commerce 
services; 

plural, distributed, trusted commerce appliances supporting end-user 
electronic commerce activity; and 

at least one communications arrangement for securely conveying digital 
information between said end-user electronic commerce appliances and at least 
one said commerce utility system, securely conveying digital information between 
two or more of said commerce utility systems, and securely conveying digital 
information between said two or more of end-user commerce appliances. 

1 74. A hierarchical commerce infrastructure comprising: 

plural trusted distributed commerce appliances having associated users: 
means for establishing a programmed hierarchical rights management 
relationship between said plural distributed commerce appliances and/or said users 
of said distributed commerce appliances; and 

means for separately producing, at least in part in combination with at least 
a portion of said programmed hierarchical rights relationship and at least in part 
by the action of a more hierarchically senior: (a) distributed commerce appliance, 
(b) user using a distributed commerce appliance, (c) distributed commerce 
appliance and user, or (d) a plurality of any one or more of (a), (b), or (c) in 
combination, control information for specifically managing specific activities 
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performed by hierarchically less senior said commerce appliances and/or users of 
said appliances. 

1 75. A hierarchical commerce utility system infrastructure for supporting 
plural trusted end-user commerce nodes, said infrastructure comprising: 

a first trusted commerce utility system; 

a second trusted commerce utility system less senior than said first trusted 
commerce utility system; and 

means for communicating control information between said first and 
second commerce utility systems, 

wherein said second commerce utility system operates at least in part in 
accordance with said securely communicated control information to perform a 
commerce utility service function servicing at least one of said end-user 
commerce nodes. 

1 76. A virtual computer comprising: 

a trusted commerce utility system for at least in part managing use 
rights related to resources available at plural distributed commerce nodes; 

means for establishing use rights information to at least in pan govern 
use of physical and/or logical resources available for use at* at least one of. said 
distributed commerce nodes; 

means for securely communicating at least a portion of said use rights 
information to said at least one remote distributed commerce node: and 

means for employing resources at said at least one said distributed 
commerce nodes for use in said virtual computing arrangement based, at least in 
part on said use rights information 

177. A virtual, networked banking system comprising: 
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a web of plural, separately managed banking protected processing 
environments; and 

a communications arrangement that communicates control information 
securely between said plural, separately managed banking protected processing 
environments; 

wherein said web of plural, separately managed protected processing 
environments includes a governing arrangement that governs one or more banking 
activities, by at least in part managing, at least in part through use of rules and 
controls, interacting electronic processes at least in part operating under the 
control of said plural banking protected processing environments, said processes 
being related to one or more of: (1 ) the electronic storage of currency, (2) the 
right to lend money to at least one participant, (3) the fulfillment of payment 
obligations, (4) the management of electronic bills and/or other obligations, and 
(5) the ability to deliver or otherwise communicate one or more currency objects. 

178. A system for supporting payment settlement related, at least in part, 
to electronically rights managed electronic commerce, said system including 
plural distributed electronic commerce nodes located at remote cnd-uscr siies. said 
system comprising: 

at least one financial clearinghouse including: 

a communications arrangement for securely receiving payment 
related information from at least one of said distributed electronic 
commerce nodes; and 

a protected processing environment coupled to the communications 
arrangement* the protected processing environment processing at least a 
portion of said payment related information, said processing including at 
least in part governing payment fulfillment information at least in part 
based upon electronic rights management control information processed. 
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wherein the communications arrangement securely communicates paymen 
fulfillment related information to at least one of (I) a payment fulfillment 
organization, and (2) an intended recipient of payment, wherein said payment 
fulfillment organization and/or intended recipient of payment at least in part 
employs a protected processing environment to access said payment fulfillment 
related information. 

179, A fulfillment server for efficiently managing electronic requests, said 
fulfillment server comprising: 

a communications arrangement for securely receiving electronic request 
information from at least one distributed, trusted electronic commerce node and 
for securely receiving, from a remote location, rule based control information 
securely associated with said electronic request information, said rule based 
control information operating with fulfillment server control information to form 
at least one control set arrangement; and 

a processing arrangement coupled to the communications arrangement, the 
processing arrangement testing to determine what action should be taken with 
respect to said request information, through the use of at least a portion of said 
control set arrangement and processing, in accordance with at least a portion of 
said at least one control set arrangement, a request described by said request 
information, said processing including one or more of: (a) at least partially 
fulfilling said request, (b) declining to fulfill said request, and (c) seeking further 
information related to said request, 

wherein said processing arrangement securely responds, through said 
communications arrangement, to said one of said distributed electronic commerce 
nodes to provide feedback regarding said request information. 

1 80. A system for supporting delegated electronic rights comprising: 
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plural distributed trusted electronic commerce nodes for use by plural 
separate parties; and 

a digital credentialing arrangement that associates a digital credential with 
one or more of said parties and/or nodes, wherein said credential, in combination 
with protected control information, enables the right to said one or more parties 
and/or nodes to electronically represent and/or exercise rights possessed by one or 
more other parties and/or nodes and enables at least one right to represent and/or 
exercise at least in pan through the use of electronic control information. 

wherein at least one of said trusted electronic commerce nodes governs 
said right to represent and/or exercise by processing at least a portion of said 
control information. 

1 8 1 . A system for supporting a virtual entity comprising: 
plural distributed, trusted electronic commerce nodes for use by plural 
parties, one or more said trusted electronic commerce nodes securely creating one 
or more digital credentials representing a virtual entity comprising a cooperative 
participation among plural parties and/or nodes for one or more commercial 
purposes; 

a digital credentialing arrangement that issues digital credentials to said 
plural parties and/or nodes to at least in part represent the identity of said parties 
and/or nodes; and 

a secure communications arrangement that securely communicates among 
said plural parties and/or nodes, digital information related to at least in part the 
identity of said parties and/or nodes, 

wherein said system employs at least one of said one or more credentials 
representing said virtual entity to, at least in part, enable said virtual entity to at 
least in part participate in at least one commercial process. 
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182. A system for securely electronically delivering digital information 
between plural participants employing protected electronic environments, said 
system comprising: 

a secure communications arrangement for securely communicating 
selected digital information between two or more participant parties supported by 
at least one trusted service provider participant, wherein said trusted provider 
supports archiving and/or authenticating of transaction related information; 

means at two or more of said trusted electronic environments for securely 
generating secure control information and for securely governing at least a portion 
of said communicating and use of said selected, communicated digital information 
through use of said generated control information; 

means coupled to each of said trusted electronic environments for storing 
information related to communication and/or usage of said communicated digital 
information at each participant site; and 

means at said trusted service provider participant for performing trusted 
archival and/or authentication services related to said selected digital information 

1 83. An arrangement for reporting electronic commerce event, user 
profiling, and surveying information in the context of a system including 
distributed electronic commerce nodes having means for monitoring and 
governing usage of digital information, and means for collecting user profiling 
and/or survey information and securely reporting information related to said 
profiling and/or surveying from at least one said commerce nodes to at least 
commerce utility system service, further characterized by: 

an arrangement that electronically instructs said system service, in 
accordance with rules and controls associated with said communicated profile 
and/or survey related information, to electronically, securely communicate to at 
least one digital information rightsholder. certain of said user profiling and 
surveying information related to usage. 



user 
one 
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1 84. A trusted third party certification authority arrangement for use with 
three or more electronic commerce participant sites each having at least one 
associated user, said trusted third party certification authority arrangement 
comprising: 

a certifying arrangement for certifying at least one commercial 
capability, commitment, and/or other attribute related to at least two of said three 
or more electronic commerce participant sites and/or said users of said sites, and 
securely providing an associated digital credential to at least one electronic 
commerce participant site different from said at least two of said three or more 
electronic commerce participant sites and/or said users of said sites. 

wherein said at least one different electronic commerce participant site 
employs said digital credential in the performance of a commercial activity. 

185. A trusted arrangement including trusted installations for coupling 
trusted and untrusted activities at plural end user commerce nodes and at. at least 
one, trusted service provider system, each including a computer operating 
environment employing at least one trusted system component, said trusted 
installations comprising: 

a processor that performs at least one process externally to said at least 
one trusted component, said process not being concealed from said trusted service 
provider, and 

a communications arrangement that passes and/or receives information 
from said process to at least one concealed process performed within said internal 
trusted component, 

wherein at least certain internal operations of said internal trusted 
component are concealed from the users of the trusted arrangement. 

1 86. An infrastructure for multi-nodal commercial processing comprising: 
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secure electronic commerce node arrangements at independent participant 
sites for securely processing programmed rights arrangements for. at least in part, 
securely managing multi-steps of a commercial process; and 

at least one communication arrangement for securely communicating at 
least a portion of said rights control information between a first of said commerce 
node arrangements and a second of said commerce node arrangements to provide 
control information to said second commerce node arrangement for enabling the 
secure management and processing of at least one step of said multi-step process, 
wherein at least one step of said process occurs at said first commerce node and 
another step of said multi-step process occurs at said second commerce node. 

187. Apparatus as in claim 161 wherein participant A or participant B is 
the same as participant D. 

188. An arrangement as in claim 163 wherein at least one of said first and 
second digital credentials comprises a digital certificate. 

1 89. An infrastructure as in claim 174 wherein said distributed commerce 
appliances comprise a distributed commerce utility system. 

1 90. Apparatus as in claim 166 wherein said arrangement that 
electronically instructs said system service electronically instructs said system 
service to electionicaJly report differing usage information to different 
rightsholders as specified by said rules and controls, and wherein said usage 
information provided to at least one of said rightsholders includes at least a 
portion of said information not provided in useable form to said commerce utility 
system service. 
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191. Apparatus as in any one of the preceding claims 156-190 further 
including means for performing a negotiation process that supports bidding, 
auctions or electronic contracts. 

1 92. Apparatus as in any one of the preceding claims 156-191 further 
including means for supporting a secure multiparty negotiation process. 

193. Apparatus as in any one of the preceding claims 156-1 92 further 
including means for supporting the independent delivery of rules and control 
information. 

1 94. Apparatus as in any one of the preceding claims 1 56- 1 93 further 
including means for delivering control information independently of content 
information that is to be controlled by said control information. 

1 95 . Apparatus as in any one of the preceding claims 1 56-1 94 further 
including means for allowing a value chain participant to stipulate at least one 
aspect of information privacy control. 

1 96. In an electronic clearing arrangement including plural, distributed 
clearinghouse nodes performing digital information usage audit functions and 
maintaining at least one database containing a local store of information related to 
multiple uses of digital information, said database including rules securely 
supplied by at least one digital information rightshoider, and a central 
clearinghouse facility remote from at least some of said plural, distributed 
clearinghouse nodes, said central clearinghouse facility including: 

a communications arrangement for securely communicating with said 
plural, distributed clearinghouse nodes, said communications arrangement 
receiving at said clearinghouse facility information representative of said multiple 
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uses of digital information from plural distributed clearinghouse nodes'said at 
least one databases, and securely supplying to said remote clearinghouse nodes, 
separately from said rules supplied by said digital information rightsholder, rules 
for securely managing at least one portion and/or other aspect of use of said 
multiple digital information by said plural, distributed clearinghouse nodes, 

wherein said plural, distributed clearinghouse nodes securely manage said 
at least one portion and/or other aspect of said multiple uses in response to at least 
a portion of said local store of information and said rules securely and separately 
supplied by said clearinghouse facility and said at least one third party digital 
information rightsholder 

197. In a cooperative, distributed rights management commercial system 
including at least one value chain participant node, said system providing plural 
system services for use by digital information rightsholders, a commerce service 
center capable of communicating with said value chain participant mode for 
securely supporting electronic commerce by at least in part providing said plural 
system services comprising two or more of (1) financial clearing, (2) usage 
information clearing, (3) rights and permissions clearing, (4) certificate authority 
services, (5) directory services, (6) advertising management services. (7) 
repository, archiving, back up, and/or non-repudiation services, (8) certifying 
services validating that digital information and/or events have satisfied applicable 
commerce rules and controls, (9) managing distributed transaction processing in 
accordance with applicable commerce rules and controls, and ( 1 0) user and/or 
class profiling and/or marketing analysis including tailoring the direction of 
digital information to one or more specific parties and/or class of parties based at 
least in part upon said profiling and/or other analysis, said commerce service 
center being interoperable with at least one other commerce service center to 
enabling secure* cooperative use of said system services. 
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1 98. In a distributed commerce system supporting end-users using digital 
information, a service operation that performs electronic commerce support 
services, said service operation receiving digital information reflecting said end- 
user use of said digital information, said service operation including a secure 
communications arrangement for communicating digital information reflecting 
end-user use of said digital information with at least one additional service 
operation. 

199. In a rules managed electronic commerce system for directing the 
movement of digital information among participants having established identities, 
a commerce service center comprising: 

a communications arrangement for receiving acquired user profile and/or 
preference information associated with said participants; and 

a directing arrangement for directing other digital information to at least 
one of said participants based at least in part upon said conveyed profile and/or 
preference information, said directed digital information at least in part ensuring 
satisfaction of requirements specified by rightsholders in said directed digital 
information through use* at least in part, of rules and controls specified by said 
rightsholders 

200. In a rules and controls based, distributed commerce system 
comprising plural, separate commerce service providers and plural, separate value 
chain end-users, a method of providing services comprising: 

receiving authorization; 

in response to said received authorization, participating in a first 
commercial arrangement involving plural participants comprising a combination 
of plural, separate authorized commerce service providers and plural authorized 
end-users; and 
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transferring digital information securely between one or more end-user 
sites and plural, separate commerce service providers in response, at least in pan, 
to commerce rules and controls established by one or more of said participants. 

201. In a system for reporting electronic commerce events, user profiling, 
and surveying information, said system including distributed electronic commerce 
nodes that securely monitoring usage of digital information and securely report 
information related to said monitored usage from said commerce nodes to at least 
one commerce utility system service, at least one portion of said reported usaee 
related information not. in accordance with rules and controls, being provided in 
useable form to said system service, said commerce utility system service 
including an arrangement that electronically controls, in accordance with rules and 
controls associated with said reported usage related information, electronic 
reporting to digital information rightsholders of certain of said information related 
to usage, and reports differing usage information to different rightsholders as 
required by rules and controls, and wherein said usage information includes at 
least some information not provided in useable form to said commerce utility 
system service, 

202. In a distributed electronic system for supporting distributed micro- 
transaction auditing and processing, said system including protected, distributed 
commerce nodes for auditing usage of digital information, at least some of said 
commerce nodes including means for managing micro-payment related activity 
related to said usage of digital information based, at least in part on control 
information provided by a first party, said system further characterized by at least 
one commerce utility system that securely receives information reflecting said 
commerce node auditing of usage information reported by said protected, 
distributed commerce nodes based, at least in part on control information 
provided by a second party different from said first party. 
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203. An electronic commerce and/or rights management system for 
performing at least one clearing operation, the system comprising: 

a first electronic appliance ( 1 00), 

a second electronic appliance (100*), and 

an electronic communications network (ISO) that allows the first and 
second electronic appliances (100, 100') to exchange digital signals, 
characterized in that: 

the first electronic appliance (100) performs at least a first part of the 
clearing operation, and 

the second electronic appliance (100 1 ) performs at least a second part of the 
clearing operation. 

204. An electronic commerce and/or rights management system as in 
claim 203 further characterized in that the first part of the clearing operation 
includes at least one micropayment aggregation task, and the second pan of the 
clearing operation includes at least one payment settlement task. 

205. An electronic commerce and/or rights management system as in 
claim 203 further characterized in that that the first electronic appliance ( 1 00) 
comprises a consumer appliance, and the second electronic appliance (100*) is 
installed, at least in part, within a clearing institution. 

206. An electronic commerce and/or rights management system as in 
claim 203 further characterized in that at least the first electronic appliance ( 1 00) 
includes a protected processing environment (154). 

207. An electronic commerce and/or rights management system as in 
claim 203 further characterized in that the first part of the clearing operation 
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comprises a usage metering task (116). 

208. An electronic commerce and/or rights management system as in 
claim 203 further characterized in that the first part of the clearing operation 
comprises at least one task conditioned on a digital certificate (504). 

209. An electronic commerce and/or rights management system as in 
claim 203 further characterized in that the first part of the clearing operation 
comprises at least one rights management task. 

210. An electronic commerce and/or rights management system as in 
claim 203 further characterized in that the first part of the clearing operation 
comprises at least one electronic currency management task. 

21 1 . An electronic commerce and/or rights management system as in 
claim 203 further characterized in that most of the clearing operation is performed 
by the first appliance (100). 

212. An electronic commerce and/or rights management system as in 
claim 203 further characterized in that most of the clearing operation is performed 
by the second appliance ( 1 00*). 

213. An electronic commerce and/or rights management system as in 
claim 203 further characterized in that the system further includes a third 
electronic appliance (100") coupled to at least one of the first and second 
electronic appliances (100, 100') through the network (150), the third electronic 
appliance performing a third part of the clearing operation. 

214. An electronic commerce and/or rights management system as in 
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claim 203 further characterized in that each of the first and second appliances 
(100, 1000 are capable of performing any of a financial clearing operation, a usage 
clearing operation, a rights and permissions clearing operation, a certifying 
authority operation, a transaction authority operation, and a secure directory 
services operation, and each of said operations may be distributed in different 
ways between the first and second appliances (100, 100'). 

215. An electronic commerce and/or rights management system as in 
claim 203 further characterized in that the electronic network (150) couples the 
first and second electronic appliances (100, 100') to a commerce utility system 
web. 

216. An electronic commerce and/or rights management system as in 
claim 203 further characterized in that an electronic rights holder can 
electronically choose between the first electronic appliance (100) and the second 
electronic appliance (1000. 

217. An electronic commerce and/or rights management system as in 
claim 203 further characterized in that the first and second electronic appliances 
(100, 100*) work together to perform overall transaction clearing. 

218. An electronic commerce and/or rights management system as in 
claim 203 further characterized in that each of the first and second appliances 
(100, 100*) performs each of: at least one financial clearing operation* at least one 
usage clearing operation, at least one rights and permissions clearing operation, at 
least one certifying authority operation, at least one transaction authority 
operation, and at least one secure directory services operation. 

219. An electronic commerce and/or rights management system as in 
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claim 203 further characterized in that the first electronic appliance (1 00) 
comprises a hierarchy of plural commerce utility systems (90(1), ... 90(n)). 

220. An electronic commerce and/or rights management system as in 
claim 203 further characterized in that the first electronic appliance (100) is 
organization-specific. 

221. An electronic commerce and/or rights management system as in 
claim 203 further characterized in that the first electronic appliance (1 00) is 
vertically specialized. 

222. An electronic commerce and/or rights management system as in 
claim 203 further characterized in that the first electronic appliance ( 1 00) is 
specialized by territory and/or jurisdiction. 

223. An electronic commerce and/or rights management system as in 
claim 203 further characterized in that the first and second electronic appliances 
(100. 100') communicate and coordinate as peers and in a hierarchy. 

224. An electronic commerce and/or rights management system as in 
claim 203 further characterized in that that clearing operation includes processing 
payment related information, and performing at least one payment related 
transaction. 

225. An electronic commerce and/or rights management system as in 
claim 203 further characterized in that that clearing operation includes processing 
usage related information and performing at least one usage reporting action. 

226. An electronic commerce and/or rights management system as in 
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claim 203 further characterized in that that clearing operation includes receiving at 
least one request, and performing at least one associated rights management 
transaction. 

227. An electronic commerce and/or rights management system as in 
claim 203 further characterized in that that clearing operation includes issuing at 
least one digital certificate* 

228. An electronic commerce and/or rights management system as in 
claim 203 further characterized in that that clearing operation includes securely 
providing directory information. 

229. An electronic commerce and/or rights management system as in 
claim 203 further characterized in that that clearing operation includes performing 
at least one process management transaction. 

230. An electronic commerce and/or rights management system as in 
claim 203 whether the first and second parts of the clearing operation support one 
another. 

23 1 . An electronic commerce and/or rights management system as in 
claim 203 wherein at least one of the first and second electronic appliances (100, 
100') includes a rights operating system that supports a collection of service 
application components defining at least one service function. 

232. A method for supporting a commercial electronic commerce 
infrastructure enabling plural networked commercial arrangements, said method 
comprising the steps of: 
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a. Providing security, communication, and certification information for 
m a in ta ini ng an interoperable framework for distributed, trusted, 
programmable electronic commerce 

b. Supporting, within said framework, rights components and/or other 
rights language for operation within protected electronic commerce 
installations separately operated by electronic commerce participants 

c Participating, by plural such participants, in programmed commercial 
webs, plural of said webs involving differing combinations of said 
separately managed protected processing environments 

d. Governing, at least in part; the operation of said commercial webs 
through the enforcement of control information within said protected 
electronic commerce installations, wherein such control information 
processed within at least one of said protected electronic commerce 
installations was specified by at least two of said web's participants 

233. A method for securely governing a multi-nodal commercial process, 
said method comprising 

a. Operating distributed, secure electronic commerce nodes at 
independent participant sites 

b. Programming plural, differing commercial rights arrangements for 
processing within plural of said secure electronic commerce nodes 

c Communicating securely said rights information to at least in part 
securely manage the operation of a multi-nodal multi-step process 

d. Managing at least in part securely a commercial process at least in part 
under the control of said rights information operating within secure 
electronic commerce nodes, wherein at least one step securely occurs 
at one independent site and another step securely occurs at a second 
independent site 
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FIG. 28 Example Super Distribution 




SUBSTITUTE SHEET (RULE 26) 



50/98 





SUBSTITUTE SHEET (RULE 26) 



51/98 



Z 
< 

CL 

g 

cc 
< 

CL 



Z 

< 

CL 

O 
K- 
CC 
< 
CL 



< 

o 

CC 
< 
CL 




Z 

o 

< 
a 

UJ 
DC 

a 
a 
< 

z 

UJ 

2 

< 
a. 

UJ 



Ui 

o 

CO 

d 

E 



CM 

z 
o 

§ 

< 

(0 

z 
< 



in 



< 

to 

z 



s. 


CO 


a> 


Z 


z 


Z 


o 


o 


o 








o 








< 


< 




CO 


(0 


Z 




z 


s 


cc 




1— 







o 
< 
to 
z 



z 
o 

t- 
o 
< 
to 
z 
< 
cc 



CM 

z 

g 

O 
< 
(0 



CO 

z 
g 

O 

3 

z 



SUBSTITUTE SHEET (RULE 26) 



52/98 



H 

Q 
LU 
QC 
O 

Q 
UJ 

< 

o 

LU 
GC 
O 
O 
< 



HI 

< 

CL 



Q 
O 
X 
h- 
LU 



C 

o 

« & 

3 CD 

o 2 

■C D) 
CD O) 

£ < 

CD C 
<U $ 

O E 
— >* 

CO Q 

g oj 
x 

Ul 



CO 

a 




CO 

o 

o 
< 

CO 

z 
< 

CO 

z 

QC 
LU 
CO 
3 





CM 


m 


z 


z 


Z 


o 


o 


o 


1— 


t- 


p 


o 


o 


o 


< 


< 


< 


CO 


CO 


CO 






1- 



SUBSTITUTE SHEET (RULE 26) 



Q 

h 

O < 



LU 



wo 

1=25 

LU Ui 

en </> 



53/98 




SUBSTITUTE SHEET (RULE 26) 



54/98 




SUBSTITUTE SHEET (RULE 26) 



55/98 




SUBSTITUTE SHEET (RULE 26) 



56/98 




SUBSTITUTE SHEET (RULE 26) 



57/98 




SUBSTITUTE SHEET fRULE 26) 




SUBSTITUTE SHEET (RULE 26) 



59/98 




SUBSTITUTE SHEET (RULE 26) 



60/98 




SUBSTITUTE SHEET (RULE 26) 



61/98 




SUBSTITUTE SHEET (RULE 26) 




SIIRRTmJTF SHEET (RULE 26) 



63/98 




SUBSTITUTE SHEET (RULE 26) 



IGHTS AND PERMISSIONS 

CLEARINGHOUSE ^g"~" 400 




152b 



FIG. 42A 

Consumer Registers Control Set 
To Request Updates 
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